ASP.NET MVC：这个业务逻辑应该在哪里去了？ [英] ASP.NET MVC: Where should this business logic go?

问题描述

我的工作我的第一个真正的MVC应用程序，我试图按照一般的OOP最佳实践。我重构我有一个控制器到我的域模型一些简单的业务逻辑。我最近一直在做一些阅读，它似乎pretty清楚，我应该把逻辑某处领域模型实体类，以避免贫血领域模型反模式。

I'm working on my first real MVC application and I'm trying to follow general OOP best practices. I'm refactoring some simple business logic that I had in a controller into my domain model. I've been doing some reading lately and it seems pretty clear that I should put the logic somewhere in a domain model entity class in order to avoid the "anemic domain model" anti-pattern.

该应用程序将允许人们购买租赁车位。价格是由现货的长度以及是否该客户是创业园的成员决定的。

The application will allow people to purchase leases for parking spaces. Rates are determined by the length of the spot and whether or not the customer is a member of the business park.

所以，我在我的域模型的实体类看起来像这样（简体）：

So I have entity classes in my domain model that look like this (simplified):

public class Customer
{
    int ID { get; set; }
    string Name { get; set; }
    bool IsMember { get; set; }
}

public class ParkingSpace
{
    int ID { get; set; }
    int Length { get; set; }
}

public class ParkingSpaceLease
{
    int ID { get; set; }
    DateTime OpenDate { get; set; }
    DateTime CloseDate { get; set; }
    Customer Customer { get; set; }
    ParkingSpace ParkingSpace { get; set; } 
}

编辑：只是为了澄清LeaseQuote不是一个实体类，因为它只是用来显示成本分解透视客户，而不是在任何地方持续

Just to clarify the LeaseQuote is not an entity class as it is just used to display the cost breakdown to perspective customers and is not persisted anywhere.

public class LeaseQuote
{
    int SubTotal { get; set; }
    int Discount { get; set; }
    int Total { get; set; }
}

现在，我需要能够生成针对不同的客户和停车空间组合报价应用程序的功能。引号通常会真正创建一个租赁的背景下外部访问，例如当客户来电时高达打听价格。

Now as a feature of the application I need to be able to generate quotes for different customer and parking space combinations. The quotes will normally be accessed outside the context of actually creating a lease such as when a customer calls up to inquire about a price.

那么，什么是去了解这一点的最好方法是什么？是否有意义实例化控制器的只是的在其上调用方法getQuote？

So what is the best way to go about this? Does it make sense to instantiate a new ParkingSpaceLease object inside the controller just to call a GetQuote method on it?

var lease = new ParkingSpaceLease();
var quote = lease.GetQuote(length: 168, isMember: true);
return Json(quote);

还是应该LeaseQuote类有方法？

Or should the LeaseQuote class have the method?

var leaseQuote = new LeaseQuote();
var quote = leaseQuote.GetQuote(length: 168, isMember: true);
return Json(quote);

这感觉奇怪把逻辑在实际ParkingSpaceLease类。我想这感觉那种沉重来创建一个新的租赁物件时，我知道，我不会真正用它做任何事情比访问getQuote方法，这似乎有点像一个单独的服务等。

It feels strange putting the logic in the actual ParkingSpaceLease class. I guess it feels kind of "heavy" to create a new lease object when I know that I'm not going to actually do anything with it other than access the GetQuote method which seems kind of like a separate service.

那么，应该getQuote方法去，为什么它应该去那里？

So where should the GetQuote method go and why should it go there?

推荐答案

这听起来像你LeaseQuote不是一个实体，更多的是业务水平类。我的意思是，你不是在数据库中存储的任何地方，是吗？这不是另一个数据对象的一部分。

It almost sounds like your LeaseQuote isn't an entity and more of a business level class. I mean, you're not storing it in the database anywhere, are you? And it's not a part of another data object.

当我看到这个

现在，我需要能够生成针对不同的客户和停车空间组合报价应用程序的功能。引号通常会真正创建一个租赁的背景下外部访问，例如当客户来电时高达打听价格。

Now as a feature of the application I need to be able to generate quotes for different customer and parking space combinations. The quotes will normally be accessed outside the context of actually creating a lease such as when a customer calls up to inquire about a price.

我觉得像这样的方法签名的

I think of a method signature like this

public LeaseQuote GetQuote(Customer customer, ParkingSpace parkingSpace, int length)

不过，考虑到这一点，我可能也想存储有关 ParkingSpace 实体内的停车位的费用及（如适用）客户的打折信息在客户实体。

But with that in mind, I'd probably also want to store information about the cost of the parking space within the ParkingSpace entity and (if applicable) the customer's discount in the Customer entity.

会在哪里这个东西去？在模型类（商业模式，而不是LINQ或实体模型）访问您的实体，并作为控制器提供商。

Where would this stuff go? In a model class (business model, not LINQ or Entity model) that accesses your entities and serves as a provider for your controller.

现在我知道这不是用你的模型完全按照写入。它可能仅仅是个人偏见。但是，当我想到数据模型和数据实体，他们不应该有什么是未来从数据库返回的以外的任何插件的方法。因为它出现在数据库中，他们应该只是重新present数据不变。如果你在演戏上的数据，属于数据实体上方的层。

Now I know that's not using your models exactly as written. And it could just be personal bias. But when I think about data models and data entities, they should not have any addon methods outside of what's coming back from the database. They should just represent the data unaltered as it appears in the database. If you're acting on the data, that belongs in a tier above the data entities.

更新：

什么，我从你的例子好奇的是，为什么人会想通过完整的实体对象（客户和车位）与刚刚执行计算所需的性能？

What I am curious about from your example is why one would want to pass the full Entity objects (Customer and Parking Space) versus just the properties needed to perform the calculation?

这取决于你的code标准。如果消费code操纵实体露出了实体本身可能是危险的。我preFER通过实体主要是因为这是我已经习惯了。但我也小心，不要对操作的方式的实体，我认为方法签名反映了getQuote方法的重点是。它涉及到一个客户和一个停车位

It depends on your standard of code. Exposing the entity itself could be dangerous if the consuming code manipulates the entity. I prefer passing the entity mainly because that's what I'm used to. But I'm also careful not to manipulate the entity on the way in. That, and I think the method signature reflects what the GetQuote method is focused on; it's related to a customer and a parking space.

我也可以做，如果更多的领域进入实体后，可以影响getQuote方法，那么方法签名没有改变的情况下。在这种情况下，只为了getQuote实施必须改变。

I could also make the case that if more fields go into the Entity later that can effect the GetQuote method, then the method signature doesn't have to change. In this case, only the implementation for GetQuote has to change.

简短的回答：preference

Short answer: Preference.

这篇关于ASP.NET MVC：这个业务逻辑应该在哪里去了？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！