.net - 客户端或业务层的对象构建？

Question

通过查看多个 .NET 入门工具包，我注意到的一点是业务对象构造通常在客户端级别处理。然后，将业务对象传递给业务层进行操作，序列化到数据库等。不应该把这段代码抽象到业务层，让客户端只需要传递必要的数据吗？拥有一个只接受对象作为参数的 CRUD 抽象的业务层有什么好处吗？

Answer 1

我同意你的观点，与业务层的交互应该尽可能简单，隐藏复杂类型和其他复杂性，否则有什么意义。在您的 UI 和业务对象连接起来的点上，复杂性应该尽可能接近 0。

我可以想象在那时构造相对复杂的类型是合法的场景。站点越小，< 3 层实际上比严格的 3 层更好的可能性就越大。因此，要对您所看到的入门工具包持开放态度：也许范围太小以至于严格分离关注点将是矫枉过正，他们的方法很可能适合这种情况。或者，他们正在做的事情是如此复杂这是最好的处理方式。接线或集成越复杂，或者如果有插件模型或其他东西，看似过于复杂的类型实际上可以确保一致的灵活接口。有时，一个地方的一点点复杂性可以为你在其他地方节省大量的复杂性。但更多时候情况并非如此。我的猜测是，你认为糟糕的事情确实是。. . 不好。

1. 许多微软快速入门演示 和模板的架构非常糟糕。Web 表单模型本身并不能很好地分离关注点。你会看到很多官方示例是 意大利面条代码的噩梦。业务、数据库和用户界面共存是一种可怕的和谐。
2. 如果您在谈论 3rd 方 SDK：其中许多需要将复杂类型传递给业务对象，因为它们是从 C++ 移植的，但从未真正修改为面向对象。有几次我不得不制作一些疯狂的类型来传递给一些成像软件对象，在逻辑上它只需要两个简单的值参数。

Answer 2

我通常会在服务或数据访问层中进行此类工作。也就是说，对于较小的项目，我的数据访问层返回我的域对象。对于较大的项目，我会使用服务层来处理复杂的对象构造和业务逻辑的调用。