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?

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

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.)

A bit more in depth than my posting then ;)