在BLL或UI中使用Linq-to-SQL实体？

Question

我有一个客户在前几天要求建立一个简单的WPF LOB应用程序的建议。他们基本上想要一个数据库的CRUD应用程序，主要目的是作为WPF培训项目。

我还向他们展示了Linq To SQL，他们留下了深刻的印象。

然后我解释了直接从他们的BLL或UI代码中使用L2S实体可能不是一个好主意。他们应该考虑使用类似Repository模式的东西。

在那一点上，我已经可以感觉到头脑中的过度工程警报响起（在某种程度上也在我的脑中）。对于简单的CRUD应用程序，他们真的需要所有这些复杂性吗？ （好吧，它有效地起到了WPF培训项目的作用，但让我们假装它变成了一个“真正的”应用程序。）

• 您是否认为通过您的应用程序使用L2S实体是可以接受的？
• 稍后重构使用另一个持久性框架有多困难（来自经验）？

我看到它的方式，如果UI层使用L2S实体作为一个简单的POCO（没有触及任何特定于L2S的方法），那么如果需要，以后应该很容易重构。

他们确实需要一种集中L2S查询的方法，因此需要某种方式来管理它，即使他们确实直接使用L2S实体。因此，在某种程度上，我们已经在推动DAL / DAO / Repository的某些方面。

我可以看到Repo的主要问题是L2S实体和某些域模型之间映射的痛苦。这真的值得吗？你在L2S实体上获得了很多“免费”，我认为一旦你映射到另一个模型就很难使用它。

思想？

Answer 1

使用L2S实体的唯一主要缺点是您的UI需要了解并绑定到具体实体。这意味着您的UI知道您的数据层。通常不是一个好主意。对于任何有可能严重的事情，你真的想要一个分层的方法。

也就是说，完全可以在不知道数据层的情况下在分层架构中使用LINQ-to-SQL实体：提取实体的接口并将其绑定到它们。

请记住，所有L2S实体都是部分类。创建反映您的实体的接口（Refactor => Extract Interface是您的朋友）并创建实现接口的实体的部分类定义。将接口本身（以及仅接口）放在UI和业务层引用的单独.DLL中。让您的业务层和数据层接受并发出这些接口而不是它们的具体版本。您甚至可以让接口实现INotifyPropertyChanging，因为L2S实体本身实现了这些接口。这一切都很有效。

然后，当/如果你需要一个不同的持久性框架时，你在BL或UI中根本没有痛苦，只在数据层 - 你想要的地方。

Answer 2

基本上我们为一个项目所做的是我们有一个Business层，它完成了所有“LINQing”到L2S对象......实质上是通过“Manager Objects”将所有查询集中到一个层（我想这些都有点类似于存储库）。

我们没有使用DTO映射到L2S;因为我们觉得这个项目不值得付出努力。我们逻辑的一部分是，随着越来越多的ORM支持Iqueryable和类似于L2S的语法（例如实体框架），那么转换到不同的ORM可能不会那么糟糕，所以它不是坏事，IMO

Answer 3

存储库不是什么大问题。请参阅此处以了解它们在ASP.NET MVC中的使用情况：

http://nerddinnerbook.s3.amazonaws.com/Part3.htm

Answer 4

  

您是否认为通过您的应用程序使用L2S实体是可以接受的？

这取决于。如果您使用短期产品，如果您使用L2S，则可以快速连接。但是如果你做一个长期存在的产品，你可能需要长时间维护，那么你最好考虑一个适当的持久层。

  

稍后重构使用另一个持久性框架有多困难（来自经验）？

如果您在所有图层中使用L2S，那么您不能考虑将它们重新分解为使用另一个持久性框架。这正是在持久层中使用像NHibernate或Entity Framework这样的框架的优势，虽然它需要一些额外的预备工作，但从长远来看它很容易维护

Answer 5

听起来你应该考虑WPF的ViewModel模式

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx