在 Linq to Sql 之上创建存储库模式实现对于中型面向公众的 Web 应用程序来说是一个好的设计吗?
该应用程序仅处理Sql server后端,需要快速开发
我真的很喜欢 LINQ2SQL,因为它是一个简洁的 DAL。我想到了 EF,但对于这个项目来说太多了。
非常感谢您的建议。
在 Linq to Sql 之上创建存储库模式实现对于中型面向公众的 Web 应用程序来说是一个好的设计吗?
该应用程序仅处理Sql server后端,需要快速开发
我真的很喜欢 LINQ2SQL,因为它是一个简洁的 DAL。我想到了 EF,但对于这个项目来说太多了。
非常感谢您的建议。
存储库模式起源于 DDD 的一个主要原则是创建一个可以在其生命周期内“轻松”发展的应用程序。将来,您可能会发现 Linq2Sql 无法满足您的需求,或者(更有可能)该技术已退役(因为 Linq2Sql 将支持 EF)等等。使用存储库模式意味着您正在编写针对以抽象的方式,扎实、知名的概念。实际的实现对您的各种应用程序功能是隐藏的,这意味着您可以在将来根据需要将它们换掉。
还有其他好处,例如允许使用存储库的组件独立于其环境使用。假设您有一个使用存储库的组件,然后您发现您需要能够在服务中使用该组件来执行夜间工作。您可以创建使用相同代码的服务,但使用与 Web 服务而不是数据库交互的存储库实现。您编写了一次代码,只是翻转了一些开关。
另一个重要原因是单元测试。您不需要对您的 ORM 或持久性 API 进行单元测试,您需要对原本与持久性交互的应用程序进行单元测试以确保按预期工作。
所以,是的,我认为这是一个很好的设计。
回答您在评论中提出的问题:这样的存储库会给您带来什么?L2S 已经是一个“存储库”。答案很可能是否定的。
人们交换他们的 OR 映射器多少次?它永远不会发生。如果确实如此(这不太可能),您无论如何都需要审查并重新测试整个应用程序。抽象 ORM 是通过始终付出非常高的代价来防范极不可能的成本。不是一个好的交易。
而是使用 EF,v4.1 及更高版本,并跳过存储库模式 - 您始终访问数据库并始终访问 ms SQL。