Business logic layer in ASP.NET MVC - Architecture

Question

I am fairly new to ASP.NET MVC. I am really confused about the architecture of my project. Let me explain my confusion to you guys:

In my project I have three parts which are know to all of us. These are: controllers, models and views.

Controllers reside inside Controllers folder, views go inside Views folder and models are inside Models folder.

As we all know there are two types of models: data model and business model. The data model has all the data types to be used in the project and the business models do have additional logic related to the project. In addition to it there is going to be a data layer of the application which talks to the database.

I am going to create a class library project for this data layer which will talk to database. Also, Models folder of my MVC project is going to have data models only and I am going to create a different library for business model classes as well.

Now the problem I am facing is this:

Lets say the name of my MVC project is MVCProj, name of data layer project is DataProj and that of business layer project is BusinessProj. If I define the data types inside Models folder of MVCProj, I have to include its reference in both BusinessProj and DataProj projects. Also, I then have to use BusinesProj classes in my MVCProj. Thus I have to add reference of BusinessProj in MVCProj which results in circular dependency.

I am not sure if the architecture I am envisioning is correct or not. Please help me sort it out.

Answer 1

Arsen's answer already explained very well, but I just wanted to post my own experiences (and that's too long for a comment.)

Your idea of separating Business logic and DataAcess is good. Most projects I worked on are organized in a similar manner.

What I would do in your case is:

1 - Create a project for DataAcess: MVCProj.DataAcess

2 - Create another project only to contain your database Entities: MVCProj.Entities

3 - Add a reference of MVCProj.Entities in your MVCProj.DataAcessproject

4 - Create a project for your business layer: MVCProj.Business:

5 - Add a reference of MVCProj.Entities and MVCProj.DataAcess in your MVCProj.Business project (I'm assuming business layer will call database)

6 - Add a reference of MVCProj.Entities and MVCProj.Business to your MVC project.

See the logic? Each layer is responsible for doing "its job". Now MVC controllers may call business, wich call the database to save the records. All projects share the same Entities.

The "Models" folder on the MVC project is just an example the team provided. In most examples in the web you see people calling the database (Mainly using Entity Framework) directly inside the controllers. This works, but in the long run is very bad to maintain.

Another thing most people do is: You usually don't want to return your database entities in your controllers. Perhaps they include more properties than you will need and etc. In this case you can create what is called a ViewModel. Think of a ViewModel of something like a copy of your Entity class but only with fields relevant to the View. The ViewModels are specific to the MVC project, so they will stay in a folder inside the MVC project. You may call it Models, or ViewModels, your choice.

Not going much further, but with the separation of projects I showed above you can definetly look for a Dependency Injection framework to handle all the creation of instances of the classes for you. :)

Note: It was implied but all projects except the MVC one are just plain old class libraries.

Hope this helps clarify your ideas.

Answer 2

I did a write up that I think my help some of your confusion: Entities are not Models.

TL;DR The main source of your confusion here seems to be that you think you need your "data models" (entities) in the Models folder of your MVC project. That's incorrect on two fronts. First, the Models folder is pretty meaningless. You can rename it, remove it, whatever. It doesn't effect your application at all. Second, and as the post I mentioned details, entities are not models. They are, and should be, merely representations of a table structure to give your ORM (Entity Framework, likely) some place to stuff the data it retrieves from the database.

That said, the typical approach is something like the following:

1. "DAL" class library containing your context and entities. This is where your migrations will go.
2. A "business" class library that essentially wraps your DAL and provides basically an API that your MVC project can use to get at the data. Depending on the complexity of your app, this is the layer that's most fungible, as you'll often need to draw a fine line between what is "business logic" that might be universally applicable to any application your organization develops vs. "business logic" that is related to the specific application you're developing.
3. Your MVC project, which will utilize the DAL/Business layer.

In your MVC project then, your Model folder can basically go away, or you can use it for storing view models, instead. It's common, though, to actually create a ViewModels folder for those specifically. However, it's entirely up to you.

One final note. The "business layer", could also just as well be composed of multiple different class libraries. In my organization, for example, we have a library specifically for working with our POS system, a library for connecting to an API we utilize for email lists, a library for working with Elasticsearch, etc. Our web projects just include whatever libraries they need to utilize.

Answer 3

There is no silver bullet in Architecture, all of this is not a must, but depends from the project...

The amount of layers in your application strongly depends on the requirements.

On the one hand additional layer separate the concerns(example: from DataAccess to Business Logic) on the other hand with each level you increase the amount of work, and decrease performance

Regarding your question, it is ok, when one layer depends to another, it is not ok that the third layer depends on the first one...

In your case you choose 3 level, ideally it should look like this

DataAccess, with its data classes in separate project

BusinessLogic, another project, which call data access, and convert result to its data classes

And finally on the model reference BusinessLogic only