Organizing namespaces

Peer posted on Thursday, February 04, 2010

In order to make a logical organization of my Bo’s I’ve tried to separate Bo’s in different projects. Everything else I do is according to the demo007 sample of the SLvideo.

In my test solution I implemented 2 BusinessClass (sever side) libraries,
1: Business.Company.Server containing CompanyList,CompanyInfo,CompanyEdit …
2: Business.Address.Server containing AddressList,AddressInfo,AddressEdit …
And
3: DataAcces containing CompanyList,CompanyEdit,AddressList,AddressEdit

When my testsolution grows, the number of libraries will increase to (I asume...)

There are also Silverlight side libraries
4: Business.Company.Client
5: Business.Address.Client

Project 1 and 2 share the namespace “Business”, but I can’t make a proper reference from project 3 to 2. When building project 3 The objects are found in project 1 or 2, depending when I make a reference on “project” or browse for the dll.

How should I organize the projects and namespaces when I want to separate bo’s in libraries like in this example.
I can imagine to create specific namespaces for project 1: Business.Company and 2: Business.Address. And how about the assembly name? Should it always be Business.dll ? or shall I make specific name to ? This is against the theory in video2 , the basics…

Should I create a separate (dedicated) Data Acces projects for each BO library or keep everything in one project ?

In this stadium of learning there are a lot of practical issues to solve and I would really appreciate a “best practice” advise from an experienced .Net person 

Thanks !
Peer

ajj3085 replied on Thursday, February 04, 2010

The first thing I would ask yourself is, Will the Company and Address libraries be useful and used in OTHER applications, independantly.  That is, will you have a different application which uses only the Address, or only the Company objects.

If the answer is yes, your plan seems reasonable to me.

If not, I'd recommend keeping things simplier by keeping things in the same assembly.  Otherwise, if the assemblies need to talk for some reason, you'll need even more assemblies to keep from having Company and Address reference each other, and that would be a waste if there will never been another implementation for Company or Address.

That's been my experience, at least.

Peer replied on Thursday, February 04, 2010

Thanks ajj!

My testproject is the start of e real world project and the object's belong together.

My question is driven by my way of organising things in a logical way. If the project organisation looks nice, it's easy for me and others to navigate to the right component. But if this has negative technical impact, the cost for this organisation is to high ... What if the number of classes increase, let say well over 100 (or 500)items, is there a way to make a kind of structure to keep oversight ?

According to the stereotypes in Csla, a rootobject has at least 3 appearances. List:info,Edit and these are only the rudimental types. So the number of objects will increase with a factor 4-5 easely...

As you understand I'm doing a little investigation "best practice" with csla, and every time i hit a problem I wander wat is the best possible solution.

Peer