Software Engineering
architecture project-structure layers
Updated Sun, 29 May 2022 05:15:05 GMT

Can a layer consist of multiple projects / dlls?


I am working on the architecture for a new web application and I am pretty much a complete newbie when it comes to architecture. Working my way through .NET Application Architecture Guide, 2nd Edition and learning a lot. I have decided to go for the "standard" 3-layer architecture: Presentation layer, Business layer, Data layer. Will be using ASP.NET MVC and Entity Framework.

Currently the business layer contains the logic and business entities (anemic models). I am planning to use the business entities as EF entities. That would, however, cause the data layer to have a depency on the business layer. This "problem" can be solved by moving the business entities into its own project and have the layers that have dependencies on the business entities reference that project.

  1. Is that an ok / good way of doing things?
  2. Will / can / should the business entities project be considered part of the business layer?
  3. Can a layer consist of multiple projects, that is, the layer only acts as a "logical container"? In the above mentioned book they talk about how the business layer can consist of "Business Workflow", "Business Components", "Business Entities", and I assume that each of those are a separate project (maybe even multiple projects)?



Solution

1. Is that an ok / good way of doing things?

Sure, there's nothing within that guidance that says you can only use one project per layer. For anything beyond a small application, you're going to want to separate things out into their own projects.

2. Will / can / should the business entities project be considered part of the business layer?

Absolutely. Even though you'll have multiple projects per layer, you still need to organize the projects by their logical role. So all business layer projects should be named and organized in a similar way.

3. Can a layer consist of multiple projects, that is, the layer only acts as a "logical container"?

Yes again.

You will likely end up with some "core" projects within your layers. These are the projects you create in order to avoid the circular dependencies you mentioned in your question. And it's okay to have a "business layer core" as well as "business layer application function" type projects. All of them belong to the business layer. Repeat as necessary for the other layers.

The important thing to keep in mind is to continue to observe the separation between layers that this architecture introduces. Each project within each layer needs to obey the separation of concerns rules you put in place regarding what the project is allowed to reference.

For example, don't allow a Presentation layer project access a Data layer project. It's a little harder because now you have more projects to apply that governance to, but if you use a consistent naming convention or project structure it's pretty easy to do.







External Links

External links referenced by this document: