使用部分类的实体框架POCO中的业务逻辑？

我有业务逻辑，可以坐在业务逻辑/服务层或添加到扩展域类（EF T4生成的POCO）的新成员，利用部分类功能。使用部分类的实体框架POCO中的业务逻辑？

所以我可以有：

一）bool OrderBusiness.OrderCanBeCancelledOnline(Order order) .. 或（IOrder顺序）

或

B）bool order.CanBeCancelledOnline() ... 即它本身就是知道与否的顺序它可以被取消。

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

目前我有两种混合，这看起来并不高雅。

任何有关这方面的指导将不胜感激！

来源

2010-10-03 Mark Chidlow

对我来说OO的关键是你告诉对象为你做事情。你不要把属性拉出来，自己做决定（在助手类或其他类中）。

所以我同意你对选项b）的断言。由于您需要额外的逻辑，因此在对对象执行操作的同时将对其他辅助对象的引用传递给它们进行协作也没有任何坏处。无论您是在操作本身时执行此操作，还是使用这些协作实体预先填充订单对象，都非常依赖于您当前的情况。

来源

2010-10-03 10:26:07

谢谢Brian。为了澄清我给出的'CanBeCancelledOnline'的例子，可能需要启用/禁用表单上的'取消订单'按钮 - 所以在这种情况下，我确实需要“拉出属性并自己作出决定”（我会在许多情况下，争论并不违背OO范式）。 – 2010-10-03 11:35:40

......让我们说（仅举例而言），为了确定它是否可以取消，它需要了解一些关于客户合同的内容。再次两个选项。 a）OrderBusiness类使用来自订单和合同的信息（或逻辑）来确定订单是否可以被取消。或者 b）我执行order.CanBeCancelledOnline（合同合同），逻辑保留在Order类中。我认为你会倾向于b）作为最好的方法？ – 2010-10-03 11:46:30

如果订单与客户合同有关，那么它可能暗含了对该合同的引用。所以这是第三种选择（如果有效，我宁愿选择那个） – 2010-10-03 11:48:18

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

海事组织，你应该选A.去

POCO的应该是完全是“纯老CLR”的对象。如果你开始向他们申请商业逻辑，他们不再是POCO的。 :)

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

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

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

来源

2010-10-03 10:25:50 RPM1984

谢谢。我已经阅读了关于“贫血领域模型”的文章，这似乎是你提出的。我不得不说这似乎违背了我的OO背景，但我可以理解你可能想要以这种方式保持POCO清洁。 – 2010-10-03 11:51:26

很抱歉，[POCO]（http://en.wikipedia.org/wiki/POCO）不应包含商业逻辑的说法是完全错误的。它们通常可以包含行为和逻辑，它们不应该包含特定于框架的元素，例如ORM特定的基类。你似乎几乎所描述的似乎是一个DTO：[DTO vs POCO]（http://stackoverflow.com/questions/725348/poco-vs-dto）。 – Co7e 2013-07-29 15:59:54

@Steve - 你100％正确。回到我很久以前的答案很有趣。 :) – RPM1984 2013-07-30 21:27:54

你也可以使用扩展方法给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-24 21:39:53 Aralmo

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

较长的答案：

如果你把你的逻辑服务层中的你情感上继transaction script pattern，并与anaemic domain model结束了。这可以是一条有效的路线，但对于简单和小型的项目来说，它通常效果最好。问题在于事务脚本层（您的服务层）随着它的增长而变得更加复杂。

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

如果您不确定应该选择哪种解决方案，重构您的逻辑以将其从服务层转移到域时通常不是一件太困难的工作，但您需要尽早拨打电话以使工作不会太大了。

与其中一个答案相反，使用POCO类并不意味着您不能在您的域类中拥有业务逻辑。例如特定于特定ORM的方法和接口。具有应用业务逻辑的一些功能的类显然仍然是Plain-Old-CLR对象。

来源

2013-07-24 08:40:59 Co7e

使用部分类的实体框架POCO中的业务逻辑？

回答

相关问题