Linq到SQL和逻辑分区（DAL，BLL）

Question

我们将在.Net中重建我们的一个站点。我阅读过许多文章，并且非常喜欢将我们的项目分离为数据访问层（DAL），业务逻辑层（BLL）和表示层（我们来自传统ASP，因此这对我们来说是一个巨大的举措） ）。我也很喜欢Linq to SQL。

由于Linq to SQL旨在快速开发，Linq to SQL有可能具有DAL，BLL和表示层吗？使用Linq to SQL，DAL会返回可能在BLL中修改的实体或linq代码？ DAL和BLL与Linq to SQL之间的关系似乎是一个没有共识的模糊主题 - 因为对于我们来说这是一个很大的跳跃，所以我绝对想在做任何事情之前有一个好的游戏计划。

键入数据集似乎更适合这个，但如果我能得到与Linq类似的东西，我会走这条路。

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

Answer 1

我们正在构建您所描述的内容，我们正在使用L2S来完成。一致认为DAL和BLL之间的关系有点模糊，但我们有一个独特的BLL和一个独特的DAL。我们所有的逻辑都在BLL中，所有的数据检索/修改都是通过调用DAL（使用LINQ调用）完成的。

我们的应用程序不使用任何类型的数据集。我们已经构建了实体类来表示我们的对象。现在我已经花了几个月的时间来构建其中的一部分，我没有看到我们（我）会回到数据集。

此外，我不会挂在L2S上“瞄准快速发展”。这使得它听起来像一个原型工具。我们发现它是一种工业强度工具。这可能与微软现在可能对此提出的意见相反，因为他们宁可使用EF。

兰迪

Answer 2

我建议退一步再看看您的要求。

您是否需要真正的3层（即物理部署到不同的机器）还是只需要逻辑分区？

我在我写的第一个大应用程序中犯了这个错误。我从不需要物理3层（并且永远不会需要），但是这样设计应用程序。最显着的后果是我Linq2Sql不支持断开实体上的更改跟踪。我用Linq2Sql Entity Base来解决这个限制，但是它非常糟糕地违反了持久性无知的概念（后来人们总是会更好地知道，呵呵？）。

对于应用程序体系结构，实际的n层应用程序有很多其他含义。

您将需要消息传递，数据传输对象等Linq2SQL是一个体面的ORM，与LINQ的紧密集成提供了独特的可能性。其他ORM仍然需要一些时间赶上这里。 NHibernate 3.0是隧道尽头的灯光。 如果您有简单的数据模型并且可以按照“每个表的类别”方式映射，Linq2SQL是一个很好的ORM。

对于断开连接的变更跟踪（如果进入n层，您将需要），其他ORM具有更好的支持。

，最后：

（我们从传统的ASP来得那么这 对我们是一个巨大的一步）

在这种情况下，我会特别小心。交换技术往往被低估。即使团队中最聪明的程序员也会做出错误的决定，因为他们缺乏技术经验。尽管如此，重要的是要采用新的方式并改善你的技能。那些永不失败的人永远不会成功。

Answer 3

恕我直言，LINQ to SQL是目前最好的选择。它确实使数据的工作变得无痛苦，而且几乎很有趣。 :-)如果你对LINQ to SQL感兴趣，我会看看我们的PLINQO项目。它对LINQ to SQL有一些很大的增强，使它成为一个更好的整体解决方案。

Answer 4

我会说L2S 是的DAL。单独类中的L2S +业务逻辑变成合并的DAL + BLL，DAL侧是L2S运行时，以及L2S生成的代码（数据上下文，实体类等）。

您仍然可以很容易地将它们分开，以便L2S生成的部分以及对实体和datacontext的任何扩展都位于单独的DLL中，并在独立的dll/service/etc中提供额外的业务逻辑。但是在很多情况下，没有必要将它们分开。

当使用L2S时，分离为DAL + BLL的一个原因是，如果您预见到您将转向另一种数据访问技术，或者您可能正在使用多种数据访问技术。将单独的DAL与任何特定于L2S的内容分开，可以更轻松地切换DAL。如果你想分离DAL + BLL出于这个原因，L2S DAL-DLL应该公开实体类，任何派生类或投影类，以及获取实体或集合（List等）的方法，但保持DataContext内部为DAL以避免让L2S特定的事情（L2S查询等）慢慢进入BLL。

JMHO。

---

因为别人提到L2S工具，这里是一个什么时候会再有一个更完整的总结：http://www.thinqlinq.com/post.aspx/title/linq-tools

Answer 5

我想使用LINQ的DAL和BLL概念不再有意义。因此，我在代码（父）文件夹下的“域”文件夹下放置了linq类和 一些getters &设置器。然后我创建了'Repository'类和'FontEnd'类。