What is the best way to organize this project?

Question

I am currently trying to find the best way to organize the project that I am currently working on. It will be an SDK that people can use.

However, I am struggling a bit with the organization of the project. I have several namespaces and several projects. These projects are combined into different DLLs.

When I compile everything, I have the following assemblies:

Application Application.Entities Application.DataAccess 

However, there are still several different namespaces in these assemblies, for example

 Application.DataAccess.SourceProviders Application.DataAccess.SourceParser 

So, as you can see, I do not really agree with this. I am not creating another assembly for each namespace because I feel like it is not adding a value having 10 + dll.

But I have a few questions about this here, so I can decide how I will do it.

• What are the advantages of using different assemblies for different parts of the application, instead of using only one DLL containing ALL.
• Is it good to separate DAL from logic using another project (cq assembly / dll).
• Perhaps you have some sources of information about organizing a project in a VisualStudio or SDK design.

Greetings

Timo

Answer 1

Many of them come down to personal preference, but I'll take a picture:

• What are the advantages of using different assemblies for different parts of the application, instead of using only one DLL containing ALL.

If you need to maintain DLLs separately or if you need to distribute different versions of code, then it makes sense to isolate them. If you have the ability to dynamically load assemblies and want to exclude some DLLs from different distributions (for example, to add or remove functions depending on user licensing), this provides a convenient way to do this without relying on flag compilations or various layout configurations - just remove the dlls that you don't want the user to have.

Saving code size for individual libraries may affect JIT, but I'm not sure about that. Maybe someone else can call back.

• Is it good to separate DAL from logic using another project (cq assembly / dll).

The visibility of the layer should look like this: each layer can see everything below it, but nothing higher:

 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 below it, and should only be called to the one above it.

Now imagine that 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 dividing common objects and DAL into separate assemblies, it is easy to refer to them from different projects or solutions. In this case, the web service application (possibly intended for calling from non-NET clients or third-party websites) can go directly to the DAL if it does not need BL, while other applications can go to BL, then through other layers.

The ability to share code between different types of applications, written in .NET, is a very, very powerful feature unique to .NET. Web code can be stored in its own collection of libraries, as well as code on the desktop, etc. Dividing each layer into one or several assemblies allows you to fix new projects anywhere in the pipeline, which makes sense, and guarantees that t should include, say, system.web when distributing the client application only so that the application compiles.

• Perhaps you have some sources of information about the organization’s project in VisualStudio or the SDK design.

I will try to find some links after my boss stops looking at me, typing during a meeting.

Answer 2

• The main advantage of using different assemblies is the breaking of large-scale projects - different teams or departments can work with individual components.

• Yes. Your business logic should be separate from your DAL. This is useful for architectural purposes, as well as for unit testing and integration.

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

Answer 3

• If you are going to use this DLL in several projects, definitely. If you want to be able to update / patch without the possibility of regression in other libraries, definitely. This is essentially a matter of detail.

• Usually I use mainly for detailing the unit test and the reasons in # 1.

• I found this one to get some idea, although I disagree with all of this. As with all TFS, I think this is usually just too much.

I think namespaces are essentially a form of documentation - specifying the namespace that you install, expecting all members of this namespace to have something in common.