What is the efficient layered architecture for MVC project?

Question

I'm going to start a new project which has the architecture below:

1. Entities (only entities like Customer) - Class Library
2. BLL (Business logics for Customer - models) - Class Library
3. DAL (SQL calls from this layer) - Class Library
4. CommonUtilities (Enums, common functions) - Class Library
5. MVC Web project - has views & controllers - Web project

Question 1: Is it a good practice to use this architecture? or should I improve something more to it?

Question 2: What is Web API and should I use it as a separate layer too?

Please let me know if you have better architecture for code maintainability.

Answer 1

Question 1: Is this a good practice to use this architecture? or Should I improve something more to it?

Yes. It makes all the parts of your software loosely coupled, which means you can swap an implementation of a layer by another implementation, without having the trouble of having to heavily refactor your code. You could, with this architecture, easily add a smartphone application that reuses all layers that the ASP.NET web application uses now.

Question 2: & what is Web API, Should I use it as a separate layer too?

This would mean that your web application uses a web service layer that exposes all your application functionality: the web application talks with the Web API layer by means of a web service protocol like REST, the Web API layer then uses the business logic layer. So it's an extra layer.

It might be interesting to add it if you want to allow other developers to use your business logic, or when you plan to make an extra frontend application later, for example for smartphone, of which you know you won't be able for some reason to program it in .NET, meaning you already know you won't be able to call your business logic layer directly. In that case you would need web services in between for sure.

Also, if you don't have a web service layer in between, you'll have to recompile your frontend applications everytime you have changed the implementation of one of your lower layers. If your frontend applications, however, just consume a web service, this is not the case: your application is no longer consuming DLLs, but just passing messages back and forth over an internet connection.

This does not mean you must create a Web API layer between your application and business logic layer every time. It is overkill when you know this application will be the only frontend you'll ever build for this use case, and when a API to other developers will not be required either. If you don't know for sure, or think chances are little these requirements will come, start simple, without a Web API layer. You can add that layer later if it becomes necessary.