Namespace/solution structure

Question

I apologize for asking such a generalized question, but it's something that can prove challenging for me. My team is about to embark on a large project that will hopefully drag together all of the random one-off codebases that have evolved through the years. Given that this project will cover standardizing logical entities across the company ("Customer", "Employee"), small tasks, large tasks that control the small tasks, and utility services, I'm struggling to figure out the best way to structure the namespaces and code structure.

Though I guess I'm not giving you enough specifics to go on, do you have any resources or advice on how to approach splitting your domains up logically? In case it helps, most of this functionality will be revealed via web services, and we're a Microsoft shop with all the latest gizmos and gadgets.

I'm debating one massive solution with subprojects to make references easier, but will that make it too unwieldy? Should I wrap up legacy application functionality, or leave that completely agnostic in the namespace (making an "OurCRMProduct.Customer" class versus a generic "Customer" class, for instance)? Should each service/project have its own BAL and DAL, or should that be an entirely separate assembly that everything references? I don't have experience with organizing such far-reaching projects, only one-offs, so I'm looking for any guidance I can get.

Answer 1

There's a million ways to skin a cat. However, the simplest one is always the best. Which way is the simplest for you? Depends on your requirements. But there are some general rules of thumb I follow.

First, reduce the overall number of projects as much as possible. When you compile twenty times a day, that extra minute adds up.

If your app is designed for extensibility, consider splitting your assemblies along the lines of design vs. implementation. Place your interfaces and base classes in a public assembly. Create an assembly for your company's implementations of these classes.

For large applications, keep your UI logic and business logic separate.

SIMPLIFY your solution. If it looks too complex, it probably is. Combine, reduce.

Answer 2

Hey Chris,

I recently experienced the exact same at work. Lots of ad-hoc code that needed to be structured and organised.

Its real hard at first, since there is so much. I think the best advice I could give is to just invest time in it on the wind down on a Friday afternoon, for a couple of weeks I would just pick an app/chunk of code, examine what was there, think about what we could make generic, copy it, put it into the new library wherever I thought it should be. Once I had all the code within an application migrated, I would then work on refactoring the application to work from the common framework.. This sometimes caused problems that needed to be fixed, but so long as your thorough it shouldn't be too big a deal.

Piece by piece, thats the only way to do it.

In terms of structure, I tried to kind of mimic the MS namespacing since for the most part its pretty logical (e.g. Company.Data , Company.Web , Company.Web.UI and so on.

One of the major benefits is probably the amount of code dupe removed. Yeah a little refactoring was required in the apps, but the code base is a lot leaner, and in many ways "smarter".

Another thing I noticed is that I would often have problems trying to figure out where to put stuff (in terms of namespacing) since I wasn't sure what it belonged to. Now this really concerned me, I viewed it as such a bad smell. Since the re-org everything now falls in to space much more nicely. And with the (now very small amount) of application specfic code, they get put into Company.Applications.ApplicationName This helps me really think about business objects a lot more since I dont want too much within this namespace, so I come up with more flexible designs.

Sorry for the long post.. It's kind of rambling!

Answer 3

Large solutions with lots of projects can be quite slow to compile, but are easier to manage together.

I often have Unit test assemblies in the same solution as the ones they're testing, as you tend to make changes to them together.

Answer 4

We name the assemblies in .NET the following way Company.Project.XXXX.YYYY where XXXX is Project and YYYYY is subproject, for example:

• LCP.AdmCom.Common
• LCP.AdmCom.BusinessObjects
• LCP.AdmCom.Common.Dal

We take this from a book call Framework Design Guidelines by Krzysztof Cwalina (Author), Brad Abrams (Author)

Answer 5

For large projects the approach I like to take is to have one Domain namespace for my business objects and then use Data Transfer Objects (DTO's) in my layers where storage and retrieval of the business object is needed. A DTO is a simple object that doesn't contain any business logic.

Here is a link that explains a DTO:

http://martinfowler.com/eaaCatalog/dataTransferObject.html

Answer 6

My advice, having embarked on a similar undertaking, is to not agonize over the name spaces..

Just start developing with a few important loose guidelines, because however you start out, your project is organic, and you will end up reorganizing the name spaces and classes over time.

Don't waste time talking too much about your project. Just do it.