Application Layer

Asked

Viewed 221 times

2

Based that question and that other question, in an environment that uses the Entity Framework and Asp.net MVC.

I see in many examples the non-use of the application layer, a use of the data layer (Entity Framework) in the Controller. Then comes my first doubt:

Is it really necessary to use this layer? And what are the advantages of its use?

Following the reasoning, in an environment where there are no data exclusions but an active field.

Regarding listing and deleting data (change the value of the active field):

Which layer is responsible for this? The data access layer, the application layer, or else the Controller?

The last question is about includes.

Implementing this method in the data layer (Entity Framework):

 public IQueryable<T> Query(params Expression<Func<T, object>>[] includes)
    {
        IQueryable<T> Set = this.Query();
        foreach (var include in includes)
        {
            Set = Set.Include(include);
        }
        return Set;
    }

It would be the duty of the application layer to tell which includes it will use or else the Controller?

Basically, it is not very clear to me what the real responsibility of the application layer.

Until then for me its only responsibility was to make the layer of user interaction (Controller) did not need to be related to the data layer.

  • Linked: http://answall.com/questions/51536/quando-usar-entity-framework-com-repository-pattern/80696#80696

1 answer

3


Is it really necessary to use this layer (repository)? And what are the advantages of its use?

Is not necessary.

The advantage of the layer is being able to write unit tests more easily, because instead of injecting into the repositories classes that actually access data, you can inject other things, such as other classes that work with fictitious and controlled data.

Which layer is responsible for this (data persistence)? The data access layer, the application layer, or the Controller?

The data access layer only abstracts database operations as you include, change, delete, or select objects. It is it that transforms an object into a data element that your database understands.

The application layer, in a MVC context, is almost superfluous, because the interaction of data from different models is already done by Controller.

The responsibility for amending objects is from Controller and the rules of Models, and of effectively carry out the banking operation is the responsibility of the data layer.

It would be the duty of the application layer to tell which includes it will use or else the Controller?

No. In theory the application layer organizes and validates data coming from the presentation. The Include causes the selection to force the Entity Framework to load a certain data in advance (taking advantage of the Join feature of a relational database, for example, and improving performance).

In the way its application is being developed, the Controller is becoming a hollow layer with no function. The correct thing would be to set aside the application layer concept and use only the Controller.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.