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

You should be fine as long as you retain the discipline to keep the layers properly separated.