4

我试图找到最好的方法来分离我的域逻辑和我的持久性逻辑的关注点。我正在使用 Linq-2-Sql 进行数据访问，并且一直在关注NerdDinner 教程。如果您查看第 40 页，您可以看到他们正在使用部分类来将业务规则用于他们的 Linq 生成的类。对我来说，这感觉不对（是吗？），我希望拥有自己的 POCO，这些 POCO 暴露在我的应用程序的表示层中。看起来这里的一个选项是使用单独的 DTO 类。这对我来说感觉更好，但它添加了更多代码来测试和维护。

我喜欢简单地添加部分类以在 Linq 类上强制执行业务规则，但我不喜欢将 Linq 类暴露给我的表示层，因为如果数据库发生更改，我也需要更新表示层。

DTO 方法感觉更简洁，因为如果数据库发生更改，我永远不需要更新表示层，但要处理的代码要多得多。

因此，我目前的方法是，两个类库一个带有 Linq-2-Sql DBML + 部分类，第二个带有一组只有自动生成的属性的类，然后是一个“repo”类，用于管理从Linq 组装并将其转换为IQueryable<T>.

有没有更好的办法？有更好的中间立场吗？我可以两全其美吗？如果是这样，您将如何将它们分成不同的程序集？

更新

也许，我真正需要做的是将所有 Persitence/Domain 逻辑整合到一个程序集中（与 NerdDinner 示例中使用的方法相同），然后在我的表示层中创建不同的“视图对象”，它们是非规范化版本我的 Linq-2-Sql 实体？

4

2 回答 2

3

我尽量让我的领域对象保持无知，因为我正在使用的技术将允许。对于 LINQ to SQL，我遵循了Ian Cooper提出的方法（请参阅对 LINQ to SQL 无知、构建LINQ to SQL 应用程序，第 5 部分和构建 LINQ to SQL 应用程序，第 6 部分）。基本上，您可以手动编写域对象并将它们连接到 LINQ to SQLsqlmetal以生成到数据库的映射，然后您可以手动编辑以满足您的需要。它对我来说效果很好。

Jeremy Miller 在 MSDN 杂志上有一篇关于持久性无知的好文章。请参阅工作单元模式和持久性无知。

因此，我目前的方法是，两个类库一个带有 Linq-2-Sql DBML + 部分类，第二个带有一组只有自动生成的属性的类，然后是一个“repo”类，用于管理从Linq 汇编并将其转换为IQueryable<T>.

我不喜欢这种方法。它如此猛烈地违反了 DRY。

于 2010-01-18T16:27:43.533 回答
0

你见过AutoMapper吗？如果您查看博客，您将看到您描述的情况。

于 2010-01-18T16:32:48.530 回答