我们将在.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之间的关系似乎是一个模糊的话题，没有达成共识 - 因为这对我们来说是一个巨大的跳跃，我绝对希望在潜入任何事情之前制定一个好的游戏计划。
Typed Datasets看起来更适合这个，但是如果我可以得到类似Linq的东西，那我就去那条路。
我想远离nHibernate和其他第三方库。
答案 0 :(得分：5)
我们正在构建您所描述的内容，我们正在使用L2S来完成它。同意DAL和BLL之间的关系有点模糊，但我们有一个独特的BLL和一个独特的DAL。我们所有的逻辑都在BLL中，所有数据检索/修改都是通过调用DAL（使用LINQ调用）完成的。
我们的应用不使用任何类型化数据集。我们构建了实体类来表示我们的对象。现在我已经花了几个月的时间来构建其中的一部分，我没有看到我们（我）回到数据集。
另外，我不会因为“瞄准快速发展”而陷入困境。这使它听起来像一个原型工具。我们发现它是一种工业强度工具。这可能与微软现在所说的相反，因为他们宁愿人们使用EF。
兰迪
答案 1 :(得分：3)
我建议您退后一步，再次查看您的要求。
您是否需要真正的3层（即对不同计算机的物理部署）或仅需要对应用程序进行逻辑分区？
我在我写的第一个大型应用程序上犯了这个错误。我从不需要物理3层（并且永远不需要）但是以这种方式设计应用程序。最引人注目的结果是我Linq2Sql不支持实体上的断开连接的更改跟踪。我使用Linq2Sql Entity Base来解决这个限制，但它严重违反了持久性无知的概念（事后总会知道的更好，是吗？）。
真正的n-tiers对应用程序架构有很多其他影响。
您将需要消息传递，数据传输对象等.Linq2SQL是一个不错的ORM，与LINQ的紧密集成提供了独特的可能性。其他ORM仍然需要一些时间来赶上这里。 NHibernate 3.0是这里隧道尽头的灯。 如果您有简单的数据模型并且可以以“每表类”方式映射，则Linq2SQL是一个很棒的ORM。
对于断开连接的更改跟踪（如果是n层，则需要），其他ORM可以提供更好的支持。
最后：
（我们来自经典的ASP所以这个 对我们来说是一个巨大的进步）
在这种情况下，我会特别小心。切换技术经常被低估。即使是团队中最聪明的程序员也会做出错误的决定，因为他们缺乏技术经验。尽管如此，重要的是采取新方法并提高您的技能。那些永不失败的人永远不会成功。
答案 2 :(得分：2)
我会说L2S 是 DAL。单独的类中的L2S +业务逻辑变为合并的DAL + BLL，DAL端是L2S运行时，以及L2S生成的代码（datacontext，实体类等）。
您仍然可以轻松地将它们分开，以便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
答案 3 :(得分：0)
恕我直言，LINQ to SQL是目前可用的最佳选择。它确实使得处理数据变得无痛而且几乎充满乐趣。 :-)如果您对LINQ to SQL感兴趣，我会看看我们的PLINQO项目。它对LINQ to SQL进行了一些很好的改进，使其成为更好的整体解决方案。
答案 4 :(得分：0)
我认为对于linq，DAL和BLL概念不再有意义。所以我放了linq课程和 一些吸气剂和代码（父）文件夹下的“域”文件夹下的setter。然后我创建了“Repository”类和“FontEnd”类。