Wrox Programmer Forums
|
VS.NET 2002/2003 Discussions about the Visual Studio.NET programming environment, the 2002 (1.0) and 2003 (1.1). ** Please don't post code questions here ** For issues specific to a particular language in .NET, please see the other forum categories.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the VS.NET 2002/2003 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old June 20th, 2003, 07:14 PM
Registered User
 
Join Date: Jun 2003
Posts: 5
Thanks: 0
Thanked 0 Times in 0 Posts
Default Naming conventions

I have a solution in which I would like to implement Interface Logic, Data Logic, Business Logic and Webservices now my questions are the following :

Is it best to have each of the logics in a separate project or keep everything in one project what are the pro’s and the con’s.

What naming convention would be convenient to use for such a solution (what to call the solution, projects and classes in this projects) and what convention would be best to use on the namespace.



I find some things on architecture and about multi tier applications but I haven’t found anything like examples or documents which face these standards, do you know where to find some references on these topics?
 
Old June 21st, 2003, 11:41 AM
Authorized User
 
Join Date: Jun 2003
Posts: 33
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I think the logic is definitely better encapsulated in seperate projects for scalability and maintainability purposes. Its a lot easier to change the UI if you know that it really only effects the UI. Also, business logic could be something that you may want to share between different applications.

Namespaces and naming are really what you and anybody else feels comfortable with, if you think that myCompany.Business is a good namespace for your business logic and if anybody else is looking for a business object that is where they would look then use it ;)

hth
 
Old June 21st, 2003, 02:43 PM
Registered User
 
Join Date: Jun 2003
Posts: 5
Thanks: 0
Thanked 0 Times in 0 Posts
Default

thx
I also got another reply which I will share:

I tend to separate logical layers out into separate projects even if
those layers are all going to be deployed in the same physical process.
This is partly to allow them to be tested in isolation - unit testing is
easier if the things under test can be tested in isolation. This is
particularly the case when using technologies like remoting, web
services or Windows Forms. It's nice to be able to test the business
logic without having to wire it up to a real remoting system, or plug it
into a Windows Forms application.



I'm not aware of any documented conventions for naming here. In fact I'm
not aware of any conventions at all... I usually make them up as I go
along, or go with whatever my customers want to do. I don't think it's
anything that has been prescribed.



On my current project, we have all the code in a namespace named after
the company, and then under this is a namespace for the whole
development project. (And I mean 'project' in the 'project management's
sense here rather than the VS.NET sense.) This is then divided into
sections for each of the VS.NET projects, so we have things like
Company.Foobar.DAL for the Foobar project's Data Access Layer. (And the
DAL itself is in a single VS.NET project.)



We've actually gone as far as separating out different pieces of
business logic into separate projects, so we don't have a single
LogicLayer component. But that's mostly because we have different
pieces in different physical places, so we had to do that. (But the DAL
component is actually shared by all of these projects.) But you
wouldn't go for the number of different projects we've got unless you
had a good reason to, so it's not such a good example. We've split
things up whenever we've had a specific reason to, and not otherwise.



So I would keep things in as small a number of projects as is practical,
but to remember that testing requirements are a good reason for
splitting things up. (Because it's much less practical to test a
monolith.)
 
Old June 22nd, 2003, 04:21 AM
Authorized User
 
Join Date: Jun 2003
Posts: 33
Thanks: 0
Thanked 0 Times in 0 Posts
Default

A bit more in depth than my posting then ;)





Similar Threads
Thread Thread Starter Forum Replies Last Post
recordsets- displaying and conventions jerryjet Dreamweaver (all versions) 6 February 23rd, 2008 05:43 AM
Namespace Naming Conventions For Layerd Applicatio Muhammad Zeeshan General .NET 2 September 1st, 2007 02:03 PM
Variables in the four naming conventions FJInfante SQL Server 2000 3 May 1st, 2006 01:06 PM
Naming a new table SKE Classic ASP Databases 2 March 23rd, 2005 03:25 PM
Code Writing Conventions richard.york PHP FAQs 0 April 5th, 2004 08:23 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.