【问题标题】：ASP.NET , LLBLGen and Spring.Net with Service Layer带有服务层的 ASP.NET、LLBLGen 和 Spring.Net
【发布时间】：2011-01-18 08:11:26
【问题描述】：
所以我正在考虑在这个 asp.net 项目上使用 LLBLGen Pro 和 Spring.Net，使用服务层将业务逻辑与数据存储分离。我也在考虑在 UI 层使用 PONOS，现在我的问题是：
我应该将丰富的 LLBLGen 实体对象映射到数据层还是服务层中的 Ponos？如果我在数据层中执行此操作，那么我会在服务层中丢失它们所有的丰富功能。还是我应该跳过到 Ponos 的映射并一直使用 LLBLGen 实体？如果晚一点就更难测试了吧？
有人可以告诉我这两种方法的优缺点吗？
谢谢
【问题讨论】：
标签：
asp.net
architecture
spring.net
llblgenpro
【解决方案1】：
使用不带映射的 LLBLGen 实体的好处是，您可以直接从您的数据库模式（甚至在 LLBL 3.x 中没有数据库模式）生成实体，因此您可以拥有一个非常有用的实体模型分钟。缺点是你的实体继承自 LLBL 框架类，这使得它们更难用行为/业务逻辑来丰富。如果您通常将业务逻辑设计为一组服务，这不会造成问题。
在这种情况下，我不认为测试是一个问题，因为我通常将实体视为“贫血”数据对象，并且我通常不会模拟此类对象（没有真正的理由这样做）。
映射到 POCO 的好处是您可以完全控制您的域/实体/DTO 对象的设计，并且它们可以随心所欲地丰富或贫乏。缺点是您必须设计和编码 POCO 类和映射，并且（如您所说）您将失去一些功能，例如内置于 LLBL 实体中的更改跟踪。
我个人选择使用生成的实体对象，除非我有充分的理由不这样做。