我有业务逻辑，可以位于业务逻辑/服务层，也可以添加到利用部分类功能的扩展域类（EF T4生成的POCO）的新成员中。
所以我可以：
a）bool OrderBusiness.OrderCanBeCancelledOnline(Order order) .. 或（IOrder order）
或
b）bool order.CanBeCancelledOnline() .. 即。订单本身就知道它是否可以取消。
对我来说，选项b）更多是OO。然而，选项a）允许应用更复杂的逻辑，例如使用其他域对象或服务。
目前我混合了两者，这看起来并不优雅。
非常感谢任何关于此的指导！
答案 0 :(得分：6)
OO对我来说关键是你告诉对象为你做事。你不会拉出属性并自己做决定（在辅助类或其他类中）。
所以我同意你对选项b）的断言。由于您需要额外的逻辑，因此在对对象执行操作同时传递对其他辅助对象的引用以使它们协作时没有任何害处。您是在操作本身时执行此操作，还是使用这些协作实体预先填充订单对象，这在很大程度上取决于您当前的情况。
答案 1 :(得分：2)
您还可以使用POCO的扩展方法来包装您的bll方法。 所以你可以继续使用你当前的bll。 在c＃之类的东西：
public static class OrderBusiness <- everything must be static, class and method
{
public static bool CanBeCancelledOnline(this Order order) <- notice the 'this'
{
logic ...
现在你可以做订单.CanBeCancelledOnline（）
答案 2 :(得分：2)
这可能取决于您的应用程序的复杂性，并且需要经验带来一些判断。简短的回答是，如果您的项目不仅仅是一个非常简单的项目，那么您最好将逻辑放在域类中。
答案越久：
如果您将逻辑放在服务层中，则会有效地关注transaction script pattern，最后会得到anaemic domain model。这可能是一个有效的路线，但它通常适用于简单和小型项目。问题在于，事务脚本层（您的服务层）在增长时变得更加复杂。
所以另一种方法是创建一个包含其中逻辑的富域模型。将逻辑与它所适用的类保持在一起是良好的OO设计的关键部分，并且在复杂的项目中非常重要。最初通常需要更多的思考和努力，这就是为什么对于非常简单的项目，人们有时会使用事务脚本模式。
如果您不确定要使用它，那么重构您的逻辑以将其从服务层移动到域通常不是一件非常困难的工作，但是您需要尽早拨打电话以确保工作不会太多大。
与其中一个答案相反，使用POCO类并不意味着您在域类中不能拥有业务逻辑。 POCO is about not applying framework specific structures to your domain classes，例如特定于ORM的特定方法和接口。具有一些应用业务逻辑的函数的类显然仍然是Plain-Old-CLR-Object。
答案 3 :(得分：0)
一个常见的问题，也是一个部分主观的问题。
IMO，您应该使用选项A.
POCO应该是“普通CLR”对象。如果你开始向他们应用业务逻辑，他们就不再是POCO了。 ：）
您当然可以将业务逻辑放在与POCO相同的程序集中，只是不要直接向它们添加方法，创建帮助类以促进业务规则。您的POCO应该拥有的唯一内容是映射到您的域模型的属性。
真的取决于您的业务规则有多复杂。在我们的应用程序中，业务规则非常简单，因此我们使用选项A.
但如果您的业务规则开始变得混乱，请考虑使用规范模式。