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，它只向用户公开最小属性。不用担心他会在意想不到的财产中注入一些不好的东西。现在，使用依赖注入，我会调用Facade。让我们说_accountsFacade.RegisterAccount，我会将View Model作为参数传递。在Facade中的这个方法中，我将从View Model到Model进行映射，这个Facade将负责完成所有需要完成的工作，以便创建帐户。在我看来，这是所有业务逻辑的所在。在这个Facade中，再次使用依赖注入，我使用一个Work工作单元并在上下文中添加和编辑实体。 _unitOfWork.AccountRepository.Add（帐户）你看？仅控制器＆＃34;路由＆＃34;应用程序，外观处理业务，工作单元处理上下文，存储库仅与数据库通信...并且模型仅公开属性。如上所述，这使得映射更快，并且它将问题分开。有时，添加帐户的逻辑可能涉及处理不应在帐户对象内使用的不同对象，

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

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

1 个答案: