MVP: Passive View (with EF) and layers

Question

I'm creating an application using MVP: Passive View and EF (model first). As of know, I have a presenter getting data directly from the DataContext created through EF. It looks something like this:

        private void UpdateOrderTableControl()
    {
        IList<Order> orders = dataContext.Orders.ToList();
        IList<OrderViewModel> viewOrders = new List<OrderViewModel>();
        foreach (var o in orders)
        {
            viewOrders.Add(new OrderViewModel()
            {
                OrderId = o.Id,
                CustomerId = o.CustomerId,
                LastName = o.Address.LastName,
                FirstName = o.Address.FirstName,
                Company = o.Address.Company,
                Weight = o.Weight,
                Sum = o.Sum,
                Date = o.Date
            });
        }

        view.GetOrderDataGridView().DataSource = viewOrders;
    }

So the presenter gets a list of all orders, creates a list of order view models (combining data from different tables, i.e address above) and then sends the view model list to the view.

It's pretty much the same thing the other way around, when retrieving data from the view in order to edit or add to the db:

        private void SaveOrder()
    {
        GetOrderDataFromView();

        if (isNewOrder)
        {
            dataContext.Orders.Add(selectedOrder);
        }
        else
        {
            dataContext.Entry(selectedOrder).State = EntityState.Modified;
        }

        dataContext.SaveChanges();
        isSaved = true;

        UpdateOrderTableControl();
    }

1) Can EF (the entities created through EF, the DataContext etc) be considered as the DAL? Should it be in a project of its own?

2) I guess the presenter should not have access to the DataContext like that, but rather to another layer in between the two, right? Would that be a service layer, a business layer or both?

3) Is what I refer to as a view model in fact a view model or is it something else? I just want to get my terminology right.

EDIT:

4) I read some suggestions about adding business logic to the entities generated by EF, but that doesn't sound quite right to me. Should I create business objects in a separate business layer on top of EF? Meaning I would have Order (generated by EF), OrderBO (the business object) and OrderViewModel (the order to be displayed). I would have to do more mapping, since I'd add another layer, but it would make the presenter lighter.

Thanks in advance!

Answer 1

Nice questions!

Well, the answer to all of them depeneds on what you plan to do. The first you have to do is to evaluate if the effort needed to implement each pattern is worth the pain.

1)Are you going to switch between different implementations of forms and/or have massive unit tests for the UI alone? Then yes passive view seems a good idea.

2)Is it not so much pain to have a litle code inside the forms? Then MVP supervising controller can be faster to implement.

3)Can most of the logic of your program be inside bussiness layer? After you have all the logic inside BL, how much logic is GUI specific? If it is not that much then code inside the forms with no GUI patterns is the way to go.

About the questions:

1) Yes, EF can be considered a DAL, and doesn't hurt to be in a different project. Since you are into patterns, a usefull pattern here is Repository and Unit of Work Pattern that abstracts EF and lets you unit test the BL. (test without accessing an actual database, with a fake DAL implementation)

2) Depends. EF objects can be considered Data Transfer Objects since they are POCO. DTOs are visible in all layers. Another strategy is to have layer specific objects, mainly in the scenario of a tiered application (each layer in different machine).

If not forced to do otherwise, I would have EF objects visible to all layers but the DataContext itself visible only to BL, not GUI layer. This means that queries and transactions are done in BL but GUI can get the results in the same format.

3) If you follow the above advice, this rather bad object copying isn't needed.

4) This strategy you refer to is the Domain Model (google for more), in which you put logic inside the domain objects, that can also access the database. Again if you follow the advice in 2), this doesn't bother you.

Before getting frustrated around patterns and their correct implementations though, really focus on your needs! The goals are fast delivery and easy maintainance. Too much abstraction can hurt both!

Answer 2

Regarding the question #2, it will be better to differentiate and make some abstractions on Data Access Layer. If you continue keep it inside Presenters, that means your client will ask database each time, load some data and then make some calculations. If you are working on Client-Server application, it will be better to not mix-up the server logic and client logic. Presenters are definitely on client side, DAL on server-side. You can connect client to server with web services (ex. asmx, wcf). I see at least three huge reasons to do this:

1. Ability to write simple unit tests on your presenter without real back-end and server logic
2. Scale your server side if needed.
3. You will be able to send less data to client if you make some required calculations on server side

Regarding #3, with passive-view pattern, there is a Presenter, which requesting data (sometimes it called Model), prepare it to display and send to View to render. In Model-View-ViewModel pattern, ViewModel will send request to server and prepare data to display. The difference between MVVM and PassiveView how Presenters and ViewModels are working with View. In PassiveView Presenter will know about View's interface to be able to send data to render. In MVVM View knows about ViewModel and bind data from ViewModel.

The last one, #1. I think yes, it is some Infrastructure layer. If you make an abstraction here, you will be able to move some optimization commands, set loading options (EF is very flexible here) and you will be able to do it quickly.