从文件后面的代码中分离Linq To SQL查询

Question

  

可能重复：
  Should I use Linq To SQL directly in code behind or use some other approach?

我之前已经问了一个问题Separation Of Linq Queries from code behind.

也许我无法得到我正在寻找的答案。所以我再次问它。我直接在linq使用Sql到code behind次查询。 我虽然使用函数。

我的问题是我应该如何从code behind分隔出来？

什么是更好的方法。我应该使用简单的classes并在那里执行我的database操作(querying,insert,update,delete)，然后从后面的代码中调用这些函数。

这是我应该遵循的方法吗？如果是，那么我应该去一个班级，还是应该每页创建一个班级。

任何人都可以指导我如何组织这个。你们关注的方法是什么？

我正在使用ASP.NET Web Forms/C#。

一个简单的例子将是一个巨大的帮助。

欢迎任何建议。

Answer 1

您可以选择N层方法，您将拥有数据访问层，业务层和表示层。 您的数据访问层将具有LINQ to SQL内容，您的业务层应该作为数据访问层和表示（UI）层之间的桥梁。

请查看以下文章：Using LINQ to SQL in N-Tier Architectures

Answer 2

在某些方面，LINQ查询实际上不应被视为“SQL”查询，即使它们被传递给LINQ2SQL或EF提供程序。可以说LINQ表达式可以被视为查询标准模式的灵活实现，例如类似于Evan's specification pattern，指定要返回的“什么”，理想情况下保持SQL细节至少“如何”执行此操作。

也就是说，如果您将DataContext或IQueryable直接暴露给您的演示文稿层，它可能会使系统难以测试。通常，您可能希望考虑将LINQ表达式约束为专用的“数据层”。

修改的

这里有类似的讨论： http://social.msdn.microsoft.com/Forums/en-NZ/linqtosql/thread/2df752fd-6a1d-441b-b7c4-ecf1a7a00161

具体来说，这里有Linq2SQL的通用存储库模式 http://multitierlinqtosql.codeplex.com/

然而，在Linq2SQL中实现高度分层的架构之前，您可能会重新考虑用Entity Framework 4+替换Linq2SQL。例如L2SQL的一个问题是实体是上下文绑定的，这意味着如果你想要打破在需要使用你的实体的任何层周围携带DataContexts的依赖性，你需要映射简单数据实体（POCO） 。 IMO Linq2SQL最适合那些你觉得不需要抽象太多的小项目。