在服务层中更新模型，而无需在MVVM中读取整个实体

Question

As known, the service layer is responsible for updating (and of course reading, writing and deleting) the models (or I may call them entities). Let us ignore Repository layer for now, because I do not like it, it just hides a lot of Entity Framework features.

The flow of data in a well designed system should be:

Service (model) <<<-->>> Controller (mapping Model <-> ViewModel)

To be able to update the Model in the database by the above data flow, I have to read the whole model from the database to the service to the controller, and use AutoMapper (for example) to map the data I got from the ViewModel to the Model (now we have the old model with some changed values). Now I can pass that edited Model back to the Service, and execute DbContext.Update(Model) .

The cons of that is:

• We had to issue additional read query to read the whole model (We had to do that, otherwise, DbContext.Update(Model) will leave the none mapped Property to default).

• Also, Update query has been generated for the whole model (although I might only changed small part of the Model.)

I sometimes find that design patterns forces to hide a lot of feature which may make the program more efficient.

Is there any approach (or let us say a design pattern or any editing to service pattern) where I can map ViewModel to Model, and pass the Model to the Service, and update only the mapped Properties (so there is no need to read the whole entity before mapping the properties)?

Answer 1

My answer could be a little bit off topic, but I'm posting it anyway, because I feel like what I want to say it's a little to broad topic for comment.

You say

As known, the service layer is responsible for updating (and of course reading, writing and deleting) the models (or I may call them entities).

The thing is, that service layer shouldn't actually be used like this. I mean - you should not have so called services at all. What you're describing is known as anemic domain model . It's combination of entities and services, where entities are simple data structures (not proper objects!) and services are used to perform operation on top of entity.

In Martin Fowler's words

[...] there are a set of service objects which capture all the domain logic, carrying out all the computation and updating the model objects with the results. These services live on top of the domain model and use the domain model for data.

And this is bad.

Combine methods and data inside one object. Then what you will be looking for would be Unit of Work design pattern. In fact Entity Framework already implements this pattern. As for implementing this rich-objects approach with EF (or actually any ORM you can use in .NET for that matter) I recommend Vaughn Vernon's post about designing aggregates with EF . It's impossible to summarize this whole post, but in order to avoid link-only answer: basically Vaughn proposes two methods: creating Separated Interface with an implementation class and domain object being backed-up by something he calls state object.

To address comments: Basically yes - suggestion is to bring data and methods together instead of having one so called entity (which is simple data structure used only for getting data from DB in most cases) and separate class called service, which performs actions upon entity.

As good and fun idea this might be, this is still all theoretical, right? Second link is about putting this approach to work. Naturally, when you would start to refactor your code pivoting from anemic domain model to rich domain model you would have to ask yourself a question - how do I store my rich object in database? I mean - whole purpose of this is to encapsulate business (domain) logic inside object without having to deal with all this technical clutter. We aim for as pure C# object as possible meaning - with as less dependencies as possible. Let's talk examples. Imagine you have Order and Product class.

[Table("orders")]
class Order
{
    [Key]
    public int Id { get; set; }
    public List<Product> Products { get; set; }
    // rest omitted for clarity
}

[Table("products")]
class Product
{
    [Key]
    public int Id { get; set; }
    [Required]
    public string Name { get; set; }
    // rest omitted for clarity
}

With anemic domain model you would have service performing actions like

class OrderService
{
    public void AddProduct(int orderId, int productId)
    {
        Order order = this.orderRepository.FirstOrDefault(orderId);
        Product product = this.productRepository.FirstOrDefault(productId);

        if(!order.Products.Contains(product)
        {
            order.Products.Add(product);
        }

        this.orderRepository.Save(order);
    }
}

With rich domain model you would have class like this

[Table("orders")]
class Order
{
    [Key]
    public int Id { get; set; }
    public List<Product> Products { get; set; }

    public bool AddProduct(Product product)
    {
        if(this.Products.Contains(product))
        {
            return false;
        }

        order.Products.Add(product);

        return true;
    }

}

This class would be used in controller like

class OrderController
{
    public ActionResult AddProduct(int orderId, int productId){
        Order order = this.orderRepository.FirstOrDefault(orderId);
        Product product = this.productRepository.FirstOrDefault(productId);

        bool productAdded = order.AddProduct(product);

        // do something else
    }
}

Note two things: 1. We moved technical stuff to controller and encapsulated business logic inside Order class (let's pretend if(this.Products.Contains(product) is our only business rule) [good thing] 1. Order class should have only business-related stuff. ORM-specific annotations are introducing nothing but technical noise when it comes to reading and understanding this class, not to mention we have unnecessary dependencies inside our model [bad thing]

Vaughn discusses two ways of dealing with this. You either extract separated interface with your business methods

interface IOrder
{
    bool AddProduct(Product product);
}

And then implement it in your class like class Order : IOrder . Drawbacks of this solution are pointed out in linked blog post

The Ubiquitous Language is not really reinforced by using interfaces such as IProduct, IBacklogItem, etc. IProduct and IBacklogItem are not in our Ubiquitous Language, but Product and BacklogItem are. Thus, the client facing names should be Product, BacklogItem, and the like. We could accomplish this simply by naming the interfaces Product, BacklogItem, Release, and Sprint, but that would mean we would have to come up with sensible names for the implementation classes. Let's just pause there and move on to the second and related issue.

and

There is really no good reason to create a Separated Interface. It would be very unlikely that we would ever create two or more implementations of IProduct or any of the other interfaces. The best reason we have for creating a Separated Interface is when there could be or are multiple implementations, and is just not going to happen in this Core Domain.

Other solution is creating two objects - one for business logic only and other responsible for change tracking and used to communicate with database. With this approach you have business object without any signs of irrelevant from business point of view details. As Vaughn concludes

In the end our goal is to stay out of the way of Entity Framework

This is really broad subject. It's hard to try to explain it in SO fashion - there are whole books about this topic ;-). Generally I would recommend you reading Vernon's book titled Implementing Domain-Driven Design . It's about DDD, but it also shows how you can write proper object-oriented code.