【发布时间】：2010-12-27 18:01:16
【问题描述】：
通过查看多个 .NET 入门工具包，我注意到的一点是业务对象构造通常在客户端级别处理。然后，业务对象被传递给业务层进行操作，序列化到数据库等。不应该把这段代码抽象到业务层，让客户端只需要传递必要的数据吗？拥有一个只接受对象作为参数的 CRUD 抽象的业务层有什么好处吗？
【问题讨论】：
标签： .net architecture client business-objects separation-of-concerns
【发布时间】：2010-12-27 18:01:16
【问题描述】：
我同意你的观点，与业务层的交互应该尽可能简单，复杂类型和其他复杂性隐藏，否则有什么意义。在您的 UI 和业务对象连接起来的点上，复杂性应尽可能接近 0。
我可以想象在那时构造相对复杂的类型是合法的场景。站点越小，复杂，以至于这是处理它的最佳方式。接线或集成越复杂，或者如果有插件模型或其他东西，看似过于复杂的类型实际上可以确保一致的灵活接口。有时，一个地方的一点点复杂性可以为你在其他地方节省大量的复杂性。但更多时候情况并非如此。我的猜测是，你认为糟糕的事情确实是。 . . 不好。
- 许多微软快速入门演示 和模板真的很糟糕 建筑。网络表单模型 本身并不适合善 关注点分离。你会看到的 很多官方的例子是 spaghetti code 噩梦。 业务、数据库和用户界面 住在一起是可怕的和谐。
- 如果您说的是第 3 方 SDK：其中许多需要复杂的 传递给业务对象的类型 因为它们是从 C++ 移植的 但从未真正修改为 面向对象。有几次我不得不制作一些疯狂的类型来传递给一些成像软件对象，在逻辑上它只需要两个简单的值参数。
【讨论】：
我通常会在Service 或数据访问层中进行此类工作。也就是说，对于较小的项目，我的数据访问层返回我的域对象。对于大型项目，我会使用服务层来处理复杂的对象构造和业务逻辑调用。
【讨论】：