客户或业务层的对象构建？

Question

通过查看多个.NET入门工具包，我注意到的一点是业务对象构造通常在客户端级别进行处理。然后，业务对象被传递到业务层以进行操作，序列化到数据库等。不应该将此代码抽象到业务层，以便客户端只需要传递必要的数据吗？使用CRUD抽象的业务层是否有任何优势只接受对象作为参数？

Answer 1

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

我可以想象在这一点上相对复杂类型的构造是合法的场景。站点越小，＆lt; 3层实际上可能比严格的3层更好。因此，对于您所看到的入门套件持开放态度：可能范围很小，严格分离关注点会过度，而且他们的方法可能适合这种情况。或者，他们正在做的是复杂，这是处理它的最佳方式。连接或集成越复杂，或者如果有插件模型或其他东西，看似过于复杂的类型实际上可以确保一致的灵活接口。有时在一个地方有点复杂，可以在其他地方为您节省大量的复杂性。但更常见的情况并非如此。我的猜测是，你看到的确是坏事。 。 。 坏

1. 许多微软快速启动演示 和模板非常糟糕 体系结构即可。网络表单模型 本身并不适合自己 关注点分离。你会看到的 很多官方的例子都是 spaghetti code做恶梦。 业务，数据库和用户界面 和睦相处是一种可怕的和谐。
2. 如果你在谈论第三方 SDK：其中许多都需要复杂 传递给业务对象的类型 因为它们是从C ++移植的 但从未真正修改过 面向对象。有几次我不得不将一些疯狂类型传递给一些成像软件对象，逻辑上它只需要两个简单的值参数。

Answer 2

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