Layered Architecture Inside One Assembly

Question

I Prefer to separate my 3 layer .NET applications into separate projects to enhance modularity and separation of concerns, but i have performance issues on my computer (not enough memory and processing power) so visual studio is slow and not pleasing to work with when there is many projects in one solution, so i though of putting all the layers in one assembly but still use the code and design it as if each type is in its respective layer. I want to know one thing, if any of you have tried doing this, is there anything you recommend or don't or any idea regarding this ?
I am not looking for a discussion, i just want to know if there is any serious risks doing it this way ?

Answer 1

One of the reasons that layering is beneficial in .NET and other strongly-typed platforms is that you can't (easily) add circular references between projects/libraries. This ensures that, at least at the package level, dependencies will form a Directed Acyclic Graph (DAG). This is a good thing, because it forces us to reduce coupling .

In C# , it's perfectly possible to compile code that forms Cyclic Graphs ( ClassA references ClassB , which references ClassC , which in turn references ClassA ). Thus, putting all code into a single Visual Studio C# project removes some of the compile-time protection that layering provides.

However, if instead you write the entire project in F# , you'll regain that compile-time protection, because F# code doesn't compile if it contains cycles (although one can declare specific exceptions to that rule within a module... see the section on Mutually Recursive Types ).

So, if write the entire application in C#, you're most likely going to have problems, but if you write it in F#, you should be good.

Answer 2

The main risk is that your layering will erode over time as you make code changes. This happens because you or your team don't realize when they are making a code change that they are breaking the layering (relatively obvious when you had separate projects).

If it is just you and you have the whole codebase clearly in your mind this probably isn't a problem. Otherwise you could use namespaces to make it easier to know to which layer any class is considered to belong.

Of course there is nothing in the language preventing bad dependencies between namespaces creeping in. To be sure of this you would need something outside of the language to define and enforce the layering. This typically means using a separate tool to define the architectural components and dependency rules, map them to the code, and detect when rules are violated. Studio Ultimate has a layer diagram which will do this, as will other tools like Lattix (dependency matrix) and Structure101 ( architecture diagrams ).

Answer 3

只要你保持纪律以保持层正确分离，你应该没事。

Answer 4

How about enforcing the architecture through unit tests? You would need an API for sorting out the dependencies, and a language for expressing the boundaries from which to write the tests.

I see that for instance NDepend has an API which maybe could be used for determining the dependencies. You could then write tests where namespaces acts as boundaries using the NDepend API and maybe reflection.

Would be cool if someone did this.

Answer 5

In my experience extremely large projects performed just as bad as multiple project solutions, when source file count was similar. Primarily this seemed to be related to disk performance (I think the machine I had was 5400 rpm disk) and blocking on reading and writing lots of files (disk I/O activity). Tons of things Visual Studio does are dealing with disk (compilation, debugging, file parsing for intellisense, etc) and this seemed to be the source of my problem.

I'd be tempted to try keeping the files in separate projects and create a solution file for each.