Disadvantageous of using entity framework layer directly into presentation layer (ASP.NET MVC) by skipping Service layer

Question

In my company, We are planning to build more than one web application on a single Database. The proposed design of each of these apps are - ASP.NET MVC as Presentation layer, Restful API as service Layer(also works as domain/business Layer) and Entity framework (EF) as data access layer.

But Many of my colleagues are asking if we could used EF directly into the presentation layer.

I can explain the separation of concern and maintainability but is there any other innate flaw in consuming EF directly when multiple apps consume the same DB

Answer 1

You have two general architecture choices. You can:

<Data Access> <--> <ASP.NET MVC Web API> <-- REST --> <Angular/SPA in Browser>

Or:

<Data Access> <--> <ASP.NET MVC>  <-- HTML --> <Web pages in browser> 

Or you can do both, and have a hybrid application that serves HTML pages as a HTML skeleton, but populates them with data from a REST source using Angular or some other data binding framework.

There isn't anything innately wrong with consuming EF classes (or Business Layer methods) and serving ASP.NET MVC pages directly, if you don't require the flexibility that a client framework like Angular provides.

You'll need the REST approach if you will be talking to two different frontends, such as a web page and a native mobile application. Each frontend will use the common REST interface.

Answer 2

I think you should distinguish between layers and tiers. A layer is just an abstraction level in code. A tier is when this layer is physically separated as a network service, e.g. a REST API.

Do you need a domain/business layer in code? Yes most likely, unless you have a very simple CRUD application. Do you need to separate this layer into a separate tier accessed through a REST API? It depends. Such a tier is necessary when you have multiple independent clients accessing the same business layer, and you want to encapsulate and protect this layer for the clients. But if the clients are developed by the same team on the same platform, it might be simpler to just use a shared library for the business logic.

Separation of concerns and maintainability can by provided by layers, so that is not an argument for turning it into a tier.

The downsides of using a shared library is that it requires all clients to be on the same platform, and that a change to the business logic will require re-deloying all clients.