What's the best way to organize this project? [closed]

Question

I'm currently trying to find out the best way to organize a project I'm currently working on. It's going to be an SDK that people can use.

However, I'm a little bit strugling with organizing the project. I'm having a few namespaces and a few projects. These projects compile into different DLL's.

When I compile all I have the following assemblies:

Application
Application.Entities
Application.DataAccess

However, in those assemblies are still a few different namespaces, like

Application.DataAccess.SourceProviders
Application.DataAccess.SourceParser 

So as you can see I'm not being very consistent with this. I'm not creating a different assembly for every namespace, because I feel it adds no value having 10+ dll's.

But I have a few questions about this here so I can make a decision on how I'm going to do it.

1. What are the advantages of using different assemblies for different parts of the application, in stead of using just 1 DLL that contains ALL.
2. Is it a good idea to seperate the DAL from the logic, by using a different project (cq assembly/dll).
3. Do you perhaps have some sources of information about project organisation in VisualStudio or SDK design.

Cheers,

Timo

Answer 1

A lot of this comes down to personal preference, but I'll take a shot:

1. What are the advantages of using different assemblies for different parts of the application, in stead of using just 1 DLL that contains ALL.

If you need to maintain the DLLs separately, or if you need to distribute different versions of the code, then it makes sense to keep them isolated. If you have the ability to load assemblies dynamically and want the ability to exclude some DLLs from different distributions (to add or remove features depending on the user's licensing, for instance), this provides a convenient way to do that without relying on compilation flags or different build configurations - just remove the DLLs that you don't want the user to have.

Keeping code size down for individual libraries may have an impact on JIT, but I'm not positive about that. Perhaps someone else can chime in.

1. Is it a good idea to seperate the DAL from the logic, by using a different project (cq assembly/dll).

Layer visibility should go like this: each layer can see everything below it, but nothing above:

UI
Controller layer (populates the UI, interacts with the logic/business objects)
Business objects
DAL
Database.

In general, each layer should only talk to the one directly below it, and should only be called by the one directly above it.

Now, imagine you have a set of applications like this:

[asp.net web site]    [Winforms client]    [windows service]   [web service]
        |                    |                     |                |
web business objects    desktop logic        service logic          |
        |                                                           |
         \-------------------|--------------------/                 |
                             |                                      |
              generic business objects (BL)                        /
                             |                                    /
                            DAL ----------------------------------
                             |
                            SQL

By separating the generic objects and DAL into separate assemblies, it's easy to reference them from different projects or solutions. In this case, the web service app (perhaps intended to be called from non-.NET clients or 3rd-party websites) can go directly to the DAL if it doesn't need the BL, while the other apps can go to the BL, then through the other layers.

Being able to share code between different types of applications, all written in a .NET language, is a very, very powerful feature that is unique to .NET. Web-specific code can be stored in its own collection of libraries, as can desktop-specific code, etc. Separating each layer into one or more assemblies lets you patch new projects anywhere into the pipeline that makes sense, and ensures that you don't have to include, say, system.web when distributing a client app just so that the application will compile.

1. Do you perhaps have some sources of information about project organisation in VisualStudio or SDK design.

I'll attempt to find some links after my boss stops staring at me typing during a meeting.

Answer 2

1. The main advantage of using different assemblies is for breaking down large scale projects - different teams or departments can work on separate components.

2. Yes. Your business logic should be seperate from your DAL. It's useful for architectural reasons as well as Unit & Integration Testing.

3. This is very subjective and depends on the size of your project, team, organisational structure, business requirements, etc.