Linq to SQL 和逻辑分区（数据访问层，业务逻辑层）

Question

我们将使用.Net重建其中一个网站。我已经阅读了许多文章，非常喜欢将我们的项目分成数据访问层（DAL）、业务逻辑层（BLL）和展示层（我们正在从经典ASP转换过来，所以这是一个巨大的进步）。我也非常喜欢Linq to SQL。

由于Linq to SQL面向快速开发，使用 Linq to SQL 可以拥有一个DAL、BLL和展示层吗？使用Linq to SQL，DAL会返回实体还是可能在BLL中修改的linq代码？与Linq to SQL相关的DAL和BLL之间的关系似乎是一个模糊的主题，并且由于这对我们来说是一个巨大的飞跃，我一定要在深入任何事情之前制定一个良好的计划。

Typed Datasets似乎更适合此类需求，但如果我可以使用Linq获得类似的功能，我会选择这个方案。

我希望远离nHibernate和其他第三方库。

- Chris Klepeis

---

分区的DAL、BLL等并不完全等同于n层。n层通常意味着物理分区。虽然在表示层和业务逻辑方面拥有逻辑（例如，程序集）分区总是很好的，但我认为这是与物理分区的分开考虑。你希望解决哪一个问题？ - Craig Stuntz

我关注逻辑分区。 - Chris Klepeis

你可以使用LinqToSql拥有独立的DAL和BLL，但是如何实现以及划分的界限需要由你自己定义。LinqToSql鼓励你模糊这条线，因此你需要积极地进行抵制，以创建清晰的关注点分离。 - Michael Maddox

Answer 1

我们正在构建您描述的内容，并使用L2S进行。虽然数据访问层和业务逻辑层之间的关系有些模糊，但我们拥有明确的业务逻辑层和数据访问层。我们所有的逻辑都在业务逻辑层中完成，所有的数据检索/修改都是通过调用数据访问层的LINQ调用完成的。

我们的应用程序不使用类型化数据集。我们已经构建了实体类来表示对象。现在我已经花了几个月的时间建造其中的一部分，我认为我们（我）不会再回头使用数据集了。

此外，我不会过于关注L2S是“面向快速开发”的。这样会使它听起来像一个原型工具。我们发现它是一种工业强度的工具。这可能与微软现在可能对它说的话相反，因为他们更希望人们使用EF。

兰迪

- Randy Minder

Answer 2

我建议退一步，再次审视您的要求。

您需要真正的三层（即将应用程序物理部署到不同的机器上），还是只需要逻辑分区？

我在编写第一个大型应用程序时犯了这个错误。我从未需要物理三层（也永远不需要），但是却以这种方式设计了应用程序。最显着的结果是，我无法使用 Linq2Sql 对实体进行断开式更改跟踪。我使用 Linq2Sql Entity Base 来解决此限制，但它非常严重地违反了持久性无知的概念（事后总是比较清楚，是吧？）。

采用真正的 n 层架构会对应用程序架构产生很多其他影响。您将需要消息传递、数据传输对象等。Linq2SQL 是一个不错的 ORM，与 LINQ 的紧密集成提供了独特的可能性。其他 ORM 在这方面仍需要一些时间来赶上。NHibernate 3.0 在这里是一个曙光。

如果您有简单的数据模型并且可以按“每个表一个类”的方式进行映射，则 Linq2SQL 是一个很好的 ORM。

对于断开连接的更改跟踪（如果要进行n层架构，则需要），其他ORM具有更好的支持。

最后：

（我们来自经典ASP，因此这是我们迈出的巨大一步）

在这种情况下，我会格外小心。切换技术往往被低估。即使您团队中最聪明的程序员也会因缺乏该技术的经验而做出错误的决策。尽管如此，重要的是要走新路，提高您的技能水平。那些从未失败的人永远不会成功。

- Johannes Rudolph

Answer 3

我会说L2S是DAL。将L2S和业务逻辑分开成为合并的DAL+BLL，其中DAL侧是L2S运行时和L2S生成的代码（数据上下文、实体类等）。

您仍然可以轻松地将它们分开，使L2S生成的部分以及实体和数据上下文的任何扩展位于单独的DLL中，并将其他业务逻辑放在单独的DLL/服务等中。但在许多情况下，没有真正必要将它们分开。

使用L2S时，将其分离为DAL+BLL的一个原因可能是您预见到将来会转移到另一种数据访问技术，或者如果您可能使用多种数据访问技术。拥有一个单独的DAL与任何L2S特定的东西分开应该更容易切换DAL。如果出于这个原因要分离DAL+BLL，则L2S DAL-DLL应公开实体类、任何派生类或投影类以及获取实体或集合（如List等）的方法，但保持DataContext内部对DAL类进行控制，以避免L2S特定的内容（如L2S查询等）渗透到BLL中。

以上仅代表个人意见。

---

由于其他人提到了L2S工具，这里有一个更完整的概述：http://www.thinqlinq.com/post.aspx/title/linq-tools。

- KristoferA

Answer 4

在我看来，LINQ to SQL 是目前最好的选择。它真的让处理数据变得轻松而且几乎是有趣的。:-) 如果你对 LINQ to SQL 感兴趣，我建议你看看我们的 PLINQO 项目。它对 LINQ to SQL 进行了一些很棒的增强，使其成为更好的整体解决方案。

- Eric J. Smith

Answer 5

我认为使用linq后，数据访问层(DAL)和业务逻辑层(BLL)的概念已不再有意义。因此，我将linq类以及一些getter和setter放在“代码”(父级)文件夹下的“领域”文件夹中。然后我创建了“仓库”类和“前端”类。

- ankitCsh