业务逻辑集成到实体框架中

Question

我已经阅读了一些关于BL的文章，但这种方法对我来说似乎违反直觉。 它似乎打破了正常的 OOP 原则。 下面是一个非常简单的示例：客户端表包含每个客户端的出生日期和性别。 预期寿命表包含 clientId、年龄和存活到该年龄的概率。

难道基本的 OOP 原则不要求将方法集成到实体中吗？ 例如，客户端类中的 calculateSPTable（） 方法。

class client {
  int clientId;
  int age;
  bool male;
  list<surviveProb> lifeExpectancy;
  void calculateLifeExpectancy(); // calculates lifeExpectancy
}
class surviveProb {
  int surviveProbId;
  int clientId;
  int age;
  double probability;
}

然而，今天的方法似乎表明，这种操作必须在一个单独的层和一个单独的类中。 在实体上运行的方法不应包含在实体框架实体中。 这似乎违反直觉。 我真的很想将方法放入 EF 实体中。 这会导致问题吗？ 我在这里错过了什么？

Answer 1

经过一些研究，我现在使用一些我认为有利于维护海豚和理解应用程序的模式。假设您想注册一个帐户。在控制器中，我将有一个仅向用户公开最小属性的 AddAccountViewModel。不用担心他在意想不到的属性中注入不好的东西。现在，使用依赖注入，我会称之为外观。假设_accountsFacade.RegisterAccount，我将视图模型作为参数传递。在立面的这种方法中，我将执行从视图模型到模型的映射，并且此立面将负责完成需要完成的所有操作，以便可以创建帐户。在我看来，这就是所有业务逻辑的去向。在此外观中，再次使用依赖注入，我使用 Work 单元，并向上下文添加和编辑实体。_unitOfWork.AccountRepository.Add（account）你看？控制器只"路由"应用程序，外观处理业务，工作单元处理上下文，存储库只与数据库通信......并且模型仅公开属性。如前所述，这使得映射更快，并且分离了关注点。有时，添加帐户的逻辑可能涉及处理不应在帐户对象中使用的不同对象，

我希望你能理解我想解释的内容，因为我的英语不是很好。有帮助吗？