1

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

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

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

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

  • 您是否认为在整个应用程序中使用 L2S 实体是可以接受的？
  • （根据经验）重构以后使用另一个持久性框架有多困难？

在我看来，如果 UI 层将 L2S 实体用作简单的 POCO（不涉及任何 L2S 特定方法），那么以后如果需要的话应该很容易重构。

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

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

想法？

4

5 回答 5

4

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

也就是说，完全有可能在分层架构中使用 LINQ-to-SQL 实体本身，而无需了解数据层：提取实体的接口并绑定到它们。

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

然后，当/如果您需要不同的持久性框架时，您在 BL 或 UI 中完全没有痛苦，只有在数据层——这正是您想要的。

于 2009-11-18T03:46:07.633 回答
1

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

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

于 2009-11-18T03:42:29.390 回答
1

存储库不是什么大问题。请参阅此处以很好地处理它们在 ASP.NET MVC 中的使用：

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

于 2009-11-18T03:44:12.540 回答
1

您是否认为在整个应用程序中使用 L2S 实体是可以接受的？

那要看。如果你做一个短命的产品，如果你使用 L2S，你可以很容易地快速连续地连接起来。但是，如果您做一个可能需要长期维护的长期产品，那么您最好考虑一个适当的持久层。

（根据经验）重构以后使用另一个持久性框架有多困难？

如果您在所有层中都使用 L2S，那么您一定不要考虑重构它们以使用另一个持久性框架。这正是在持久层中使用 NHibernate 或 Entity Framework 之类的框架的优势，虽然它需要一些额外的前期工作，但从长远来看很容易维护

于 2009-11-18T03:45:37.560 回答
0

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

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

于 2010-08-24T02:30:43.783 回答