手动编写业务对象还是使用DAL对象？

Question

假设您有三层（带名称空间）：

• 用户界面（App.UI） - 调用业务层流程并使用对象进行通信
• 业务层（App.Core） - 协调流程并使用对象使用DAL层
• DAL（App.Data） - 直接操作商店并保留对象

假设您有User表，因此会反映在App.Data.User中的DAL图层中，也可能反映在App.Data.Users中。

您的UI中有一个显示应用程序用户的视图。

要真正拥有一个独立的（分层的）应用程序，您还应该拥有可能需要手动创建的App.Core.User和App.Core.Users。

最佳解决方案（我认为）当然是： 应该有第四层 Business Objects（App.Objects），其中包含类App.Objects.User和App.Objects.Users。这些POCO将在所有层之间共享。业务层只允许使用DAL，UI只允许使用BL，但所有这些都使用App.Objects作为公共对象模型。

Asp.net MVC模板意味着直接在视图上使用DAL对象，LINQ 2 Entites本身也不会创建任何POCO ......

因此，当使用任何自动代码生成时，我们应该使用DAL对象还是手动硬编码我们的共享POCO？第一部分似乎是简单的出路但不会将DAL与UI分开（以后可能会出现安全性和可扩展性问题），第二种方法容易出错，而且对于中型数据库来说非常繁琐。

你会建议什么？

Answer 1

你所谓的App.Objects基本上就是你的领域模型，在所有层之间共享以传递数据是合乎逻辑的，但你需要决定这个模型是贫血还是活跃。