c# - 关于Web应用程序体系结构，域类和业务类之间有什么区别？

Closed. This question is opinion-based。它当前不接受答案。












                            想改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。

                        去年关闭。



我想这样构建我的asp.net web form应用程序：

1-DB
2-Data Access Layer(Using ORM[EF])
3-Repository/Unit Of Work (Pattern)
4-Business Layer
5-Service Layer
6-UI

现在，我的原始解决方案如下所示：

仅有两个类库：

我的DAL (Data Access Layer)所在的EF。
Domain Classes（自动生成）及其等效的部分类。

我对这个设计的疑问：

我应该将我的business logic放在一个新的层中，还是放在每个业务都属于相关领域类的域类层中，还是将我的业务逻辑放在网页后面的代码中？
有人可以澄清一下两者之间的区别吗
设计角度的术语（POCO，Domain Class，BusinessClass）？

最佳答案

我应该将业务逻辑放在一个新的层中，还是放在每个业务属于相关域类的域类层中，还是将我的业务逻辑放在网页后面的代码中？

您的业务逻辑应该仅在您的域/业务类中，而在其他任何地方；否则，您将冒患贫血域模型的风险，从长远来看，这通常是个坏主意。（有趣的观看）
您的服务层应仅用作业务对象之间的编排点，即，它实现流程，而业务对象则实现流程的各个步骤。

例

因此，您可能有一个OrderService类，该类位于服务层中，该类具有方法PlaceOrder并驱动进程检查Customer类（业务对象）的状态，保存Order（业务类别）（可能通过您的存储库层）添加到数据存储区，并为客户排队发送电子邮件确认邮件。（可能通过其他服务）
（请注意，这是一个非常简单的示例，不一定代表您的特定方案是最佳流程）

有人可以澄清一下这些术语在设计角度（POCO，域类，业务类）之间的区别吗？

对于大多数意图和目的，“域”和“业务”对象之间几乎没有区别。
两者都存在，可以为业务领域的解决方案建模-唯一的区别是，如果您遵循强大的域驱动设计方法，则倾向于将这些类称为“域对象”。
但是，否则，您可以将它们视为同一事物-它们封装解决业务问题所需的行为和数据。

POCO不是DTO

POCO的意思是“普通的旧CLR对象”，它基本上是一个类的实例，该类的实例不依赖于任何外部框架，这些形式的属性或从该框架的继承。

因此，例如，如果您不使用EF Code First，则通常将用EF本身在运行时使用的属性装饰EF模型类，以知道什么属性是主键，依此类推。
通过使用EF Code First，您可以避免这种情况，并在代码中包含纯POCO。
POCO和DTO通常是混合在一起的。他们根本不一样！
DTO是一类，其唯一目的是在边界（层，流程等）之间传输数据，因此，它通常只是一堆读/写公共字段或属性，而没有任何业务行为。这几乎不值得“对象”分类。
另一方面，POCO可以拥有数据和行为，就像拥有适当的Object一样，并且是Domain（如果需要的话，也可以是业务）类的理想原型。

一些想法

我还想指出与您提出的设计有关的其他事项。

首先，如果您使用的是EF，则实际上并不需要单独的工作单元，因为DbContext已经为您封装了工作单元模式。
考虑一下您是否真的需要“层次”；例如，除非您的应用程序是一个非常简单的CRUD应用程序，否则您可能会受益于使用命令/查询模式，从而无需将体系结构设计为一系列浅层的宽层（可能会导致结构不灵活），而应使用薄的垂直代码这些都是面向功能的，这意味着它们可以根据需要变浅或变深，从而导致更统一的设计，更易于适应。在此here上有趣的观看
如果您使用的是实体框架，我的诚实建议是使用代码优先；它比经典的.edmx模型方法灵活得多。
同样，可以接受EF，并使其渗透到您的服务层……然后DTO发挥作用，将这些对象转换为Web控制器可以发出的传输桶。（例如，使用here）。关于EF和业务对象的一些有趣观点Automapper **
我知道这可能会遇到很多典型的“持久性无知”建议，但是根据我的经验，这很少有问题（除非您发现自己每隔一周就要更换数据库提供者！）。

通过使用EF Code First并采用DbContext将获得的好处包括
-正确的POCO域/业务对象（您可以在单独的程序集中声明您的BO，这样它们就可以享受持久性的无知，但也可以在另一个程序集（如数据访问层）中将它们分别映射到EF）
-简化的代码库，不会在层之间进行无意义的映射

**我刚刚意识到我所有的参考文献都是针对同一个人的作品。我发誓他没有付钱让我这样做:)

更新资料

根据OP关于循环依赖问题的评论，这是一个特定场景的示例代码（用例有点不起作用，仅是说明性的）

public class EmployeeNameService
{
   readonly IEmployeeRepository _repo;
   public EmployeeNameService(IEmployeeRepsitory repo)
   {
      _repo=repo;
   }
   public string GetEmployeeName(int empID)
   {
      var emp = _repo.GetByID(empID);
      var name = emp.GetEmployeeName();//does some crazy logic based on the Employee state or whatever.
      return name;
   }
}

现在，上面的要点是EmployeeNameService驻留在服务“层”中，该“层”对存储库层和域对象“层”（这实际上不是一个层，只是一个单独的项目）都具有依赖性（引用）包含域/业务类）。因此，无需担心循环依赖。
当然，存储库将引用域对象，这很好，因为它是单向依赖项。

更新2

我以前没有提到的一件事是什么时候不遵循上述建议。如果您有一个非常简单的CRUD模型，您需要在其中接受用户输入并将其直接传递到数据存储，而中间没有任何“业务逻辑”，则只需按原计划使用简单层即可。但是，一旦有任何业务逻辑，就考虑使用上述概念。

关于c# - 关于Web应用程序体系结构，域类和业务类之间有什么区别？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35700139/

上一篇：c# - Nest Elasticsearch 搜索空值

下一篇：c# - 在 UWP(通用 Windows 应用程序)、Windows 10 中创建自定义形状控件

相关文章：

c# - HTML 扩展方法在表单中不起作用

asp.net-mvc - 在 ASP.NET MVC 中使用 Entity Framework 是否允许我的 Web 项目在不同的数据库供应商上工作

entity-framework - 如何将 Entity Framework 日期转换为不带时间部分的 SQL Server 日期

c# - 如何在 C# 中从 32 位进程运行 64 位进程？

c# - 构建后消失的用户控件

asp.net - PayPal 定期付款(订阅按钮)付款响应

javascript - 手动刷新后未引用 ScriptResource.axd

c# - 连接到 Entity Framework 中的未知数据库

c# - 数组为所有索引返回相同的值

c# - NetworkStream.Write 异步问题