LINQ to SQL模糊分离关注？

Question

我只是把它说出来，我是LINQ to SQL的新手。天哪，我对编程总的来说比较新。

无论如何，我想学习并使用 LINQ to SQL 来创建使用.NET 2.0 Framework构建的项目。该项目使用存储过程来访问数据库（前端服务器上没有动态SQL查询）。 LINQ to SQL 似乎是存储过程的一个很好的替代方案，但是将它引入我的项目会破坏“关注分离”的原则。最好不要破坏这个原则，只需在需要时编写更多存储过程吗？或者有没有办法在不违反原则的情况下使用 LINQ to SQL ？

我通常发现很难在遗留项目中添加新技术和工具而不会破坏项目的一致性。

Answer 1

通过SQL而不是通过存储过程与数据库服务器交互的代码不会违反关注点分离，只要该代码很好地模块化并且LINQ to SQL部分仅关注数据输入/检索，并且没有与其他任务（问题）混在一起。 LINQ to SQL使用不会破坏任何原则

现在，修改代码从头开始编码时不使用SP可能不是一项小任务，除了学习LINQ to SQL之外，最终可能没有任何实际好处。

Answer 2

实际上，LINQ to SQL对SoC有很大的帮助。它将您从域对象中使用SQL的事实分离出来，甚至超过了传统的基于派生程的DAL。有一堆调用存储过程的方法是穷人尝试同样的事情 - 最小化但不消除DAL和业务逻辑之间的接触点。 LINQ to SQL库成为你的DAL，你可以自由地操纵一堆愚蠢的对象而不与任何数据支持直接联系 - 还有一个额外的好处就是可以直接对你的域表达使用LINQ表达式的对象，而不是依赖于存储过程的预定排列。

Answer 3

如果项目很大并且使用了许多sprocs，那么用LINQ替换它的sprocs并不是一个明智的想法。原因应该是显而易见的，为什么这样做是不谨慎的。但是，向前推进，这绝不意味着你不应该为LINQ实现一个层。这就是我对一些较大的遗留应用程序所做的工作。实现和使用LINQ非常值得，但重写旧的sprocs以使用LINQ是不值得的（也不值得冒险）。