0

可能重复：
我应该直接在代码后面使用 Linq To SQL 还是使用其他方法？

我之前已经问过一个问题，即从后面的代码中分离 Linq 查询。

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

我的问题是我应该如何将它们与它们分开code behind？

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

这是我应该遵循的方法吗？如果是，那么我应该选择一个课程还是应该每页创建一个课程。

谁能指导我如何组织这个。你们遵循的方法是什么？

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

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

欢迎任何建议。

4

2 回答 2

1

在某些方面，LINQ 查询不应真正被视为“SQL”查询，即使它们随后被传递给一个LINQ2SQL或一个 EF 提供程序。LINQ 表达式可以说被视为查询条件模式的灵活实现，例如类似于Evan 的规范模式，指定您想要返回的“什么”，理想情况下将 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 中实现高度分层的架构之前，您可能会重新考虑将 Linq2SQL 替换为 Entity Framework 4+。例如，L2SQL 的一个问题是实体是上下文绑定的，这意味着如果您想打破对携带DataContexts需要使用实体的任何层的依赖，则需要映射简单数据实体 (POCO)。IMO Linq2SQL 最适合您不需要过多抽象的小型项目。

于 2012-07-02T05:47:38.360 回答
1

您可以选择 N 层方法，其中您将拥有数据访问层、业务层和表示层。您的数据访问层将具有 LINQ to SQL 的东西，您的业务层应该充当数据访问层和表示 (UI) 层之间的桥梁。

请看以下文章：在 N 层架构中使用 LINQ to SQL

于 2012-07-02T05:38:02.347 回答