4

我的业务逻辑可以位于业务逻辑/服务层中，也可以添加到利用部分类功能的扩展域类（EF T4 生成的 POCO）的新成员中。

所以我可以：

a) bool OrderBusiness.OrderCanBeCancelledOnline(Order order)..或（订单订单）

或者

b) bool order.CanBeCancelledOnline()..即订单本身知道是否可以取消。

对我来说，选项 b) 更面向对象。然而，选项 a) 允许应用更复杂的逻辑，例如使用其他域对象或服务。

目前我两者兼而有之，这似乎并不优雅。

对此的任何指导将不胜感激！

4

4 回答 4

6

对我来说，OO 的关键在于你告诉对象为你做事。您不会提取属性并自己做出决定（在帮助类或其他类中）。

所以我同意你关于选项 b) 的断言。由于您需要额外的逻辑，因此在对对象执行操作的同时将引用传递给其他辅助对象以使它们协作是没有害处的。无论您是在操作本身时执行此操作，还是使用这些协作实体预先填充您的订单对象，很大程度上取决于您当前的情况。

于 2010-10-03T10:26:07.747 回答
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 ...

现在你可以做 order.CanBeCancelledOnline()

于 2011-01-24T21:39:53.020 回答
2

这可能取决于您的应用程序的复杂性，并且确实需要一些经验来判断。简短的回答是，如果您的项目不仅仅是一个非常简单的项目，那么您最好将您的逻辑放在域类中。

更长的答案：

如果您将您的逻辑放在服务层中，您将有效地遵循事务脚本模式，并最终得到一个贫乏的域模型。这可能是一条有效的路线，但它通常最适用于简单和小型的项目。问题是事务脚本层（您的服务层）随着它的增长而变得更加难以维护。

因此，另一种选择是创建一个包含逻辑的丰富领域模型。将逻辑与其适用的类保持在一起是良好 OO 设计的关键部分，并且在复杂的项目中非常重要。最初通常需要更多的思考和努力，这就是为什么对于非常简单的项目，人们有时会使用事务脚本模式。

如果您不确定要使用哪个，那么重构您的逻辑以将其从服务层移动到域通常不是一项太难的工作，但是您需要尽早进行调用以使工作不会太大。

与答案之一相反，使用 POCO 类并不意味着您的域类中不能有业务逻辑。POCO 是关于不将特定于框架的结构应用于您的域类，例如特定于特定 ORM 的方法和接口。具有应用业务逻辑的一些功能的类显然仍然是普通旧 CLR 对象。

于 2013-07-24T08:40:59.013 回答
0

一个常见的问题，而且是部分主观的。

IMO，您应该选择选项 A。

POCO 应该就是“普通旧 CLR”对象。如果您开始对它们应用业务逻辑，它们就不再是 POCO 的了。:)

您当然可以将您的业务逻辑与您的 POCO 放在同一个程序集中，只是不要直接向它们添加方法，创建帮助程序类以促进业务规则。您的 POCO 唯一应该拥有的是映射到您的域模型的属性。

真的取决于你的业务规则有多复杂。在我们的应用程序中，业务规则非常简单，因此我们使用选项 A。

但是，如果您的业务规则开始变得混乱，请考虑使用规范模式。

于 2010-10-03T10:25:50.663 回答