Linq到SQL层/架构？

Question

我很抱歉我的问题可能会找一个旧的重复性问题，但我正在开始Linq to SQL我想讨论我应该使用多少层（架构）？

我正在网络上工作，主要是网站和中小型网络应用程序。我理解将应用程序划分为多层有助于其维护和增强，但坦率地说，我想要一些平衡方式，这也为我提供了快速开发和代码重用能力。我不能花太多时间在不必要的层管理上。

在我使用4层（业务对象，BLL，DAL和用户界面）之前，我对它感到困惑，因为不同的人描述了不同的层。请指导我应该使用什么和多少层？感谢

Answer 1

不要使用图层架构。使用onion architecture。

Answer 2

从架构角度来看，最重要的方面是关注点的分离。关注点分离会导致代码清晰，易于维护，可扩展等。我建议根据以下标准做出决策：

• 尝试以松散耦合的方式构建您的系统。使用消息传递而不是RPC，因为消息传递是可靠的，可扩展的，异步的，松散耦合的等等。您可以使用MSMQ或NServiceBus（用于基于服务总线的体系结构）。
• 根据关注点分离概念创建图层。对于例如您可以选择典型的3层架构，它只包含UI层，业务逻辑层（业务规则+工作流）和数据访问层或更细粒度的UI层，服务层（Facade），业务逻辑层，数据访问层，使用IoC / Dependency注入将使生活变得简单，因为没有任何层将具有直接依赖性。此外，它可以在您注入模拟时简化单元测试，而不是单元测试的实际实现。有很多IoC框架可用（NInject，Autofac，Castle Windsor，Structure Map等）。
• 尝试使用EF而不是Linq to SQL，因为后者仅适用于SQL，而EF适用于任何数据库。此外，在我看来，EF是微软创新的地方，我认为Linq to SQL可能有一天会退役。

Answer 3

很好的问题haansi。这是我在建造中小型网站时经常摔跤的事情。在我们所有的工作中，我认为我们都需要努力寻找创建可以提供最大灵活性并允许快速部署的架构的平衡。

话虽如此，我发现使用Repository Pattern对LINQ to SQL项目非常有帮助。我将其与Model View Presenter模式（对于WebForms或其他项目）结合起来，并为最小层重用提供了良好的基础。

我的Webform调用一个Presenter类，而后者又负责填充View。要填充该视图，Presenter可以调用N个存储库。存储库是封装DataContext类和LINQ to SQL调用的地方。这些调用返回模型类。

无论应用程序的大小如何，这样做的一个巨大好处是可以从您的存储库中获得最佳的重用，您可以最大限度地利用LINQ，并且您已经使用了其他软件开发人员可以轻松阅读和支持的一些模式

另一个很大的好处是，您现在已经创建了一个简单的体系结构，可以使用单元测试从Presenter测试回到存储库而不需要付出太多努力。

祝你好运！

Answer 4

我决定将一层（DAL + BLL）用于小型项目，对于大型应用程序，将使用不同的层用于DAL＆amp; BLL。我将在DAL中使用Linq，funtiosn将返回IQueryable。