Web 应用程序数据层的缺点/优势

Question

我想知道通过将我的业务逻辑和数据与我的 Web 表单分开来分层我的 Web 应用程序的长期优势（如果有的话）。 （即表单、业务逻辑、数据不在同一个文件中，但每个都在另一个文件夹中的自己的类中，或者与其他类似的类组合）。我喜欢让一切尽可能模块化，并且为了有效地做到这一点，似乎将所有代码保存在一个文件中 - 以 Web 形式使组织和重用变得更加容易。整个站点都使用了某些功能，例如管理它们自己的类和文件中的连接。我对 c# 很陌生，如果我弄乱了术语，请见谅。

谢谢

Answer 1

将代码分层带来的好处不仅仅是 C# 语言。

如果您的数据访问代码保存在单独的层中，则很容易对其进行调整以与不同的数据库一起使用。特定于数据库的代码将封装在这一层中，而客户端将使用与数据库无关的接口。因此此处的更改不会影响业务层的实现。

如果您的业务逻辑保存在一个地方，您将能够将其服务提供给其他应用程序，例如，为通过 Web 服务发出的请求提供服务。

如果您的代码干净且结构良好，那么维护工作量就会降低。每当您需要更改某些内容时，您就会知道在哪里可以找到负责的代码、要更改的内容以及如何确保更改不会影响其余代码。

对于 ASP.NET，不遵循关注点分离导致许多项目变成了巨大的代码简介——演示代码执行业务决策，代码隐藏在不存在合适的业务方法时直接与数据库对话，数据库获取从许多地方写入，数据流遵循多条难以追踪的路径，未引入所有路径的一条路径的更改将破坏完整性并导致数据损坏=>结果？几乎无法维护的代码黑匣子，任何更改都需要越来越多的努力，直到它停止 - 项目“完成”。技术破产。

Answer 2

我们通常按如下方式对应用程序进行分层（每一层都位于解决方案的单独项目中，因此位于单独的 Dll 中： 我一直追求的（首先）是拥有一个分层的应用程序

• 表示层（仅 UI 和数据绑定逻辑）
• 接口层到 业务层（定义 访问 BL 的合同）
• 业务层实现（ 实际逻辑、数据验证等...）
• 数据访问的接口层 层（定义合约 访问 DAL）
• 数据访问层 实施

然后您可以使用一些工厂来检索相应的对象。我会看看一些库，可能使用 MS 模式和实践中的 Spring.Net 或 Microsoft Unity 等依赖注入。

优点如下：

• 其所属的逻辑分离
• UI 中没有业务逻辑（开发人员必须注意这一点）
• 您的所有应用程序看起来都一样，因此了解此架构的开发人员将立即知道在哪里搜索相应的逻辑
• 可更换 DAL。这些接口定义了用于访问相应层的协定。
• 单元测试变得更容易，只需关注 BL 逻辑和 DAL
• 您的应用程序可能有许多入口点（Web 界面、Winforms 客户端、Web 服务）。它们都可以引用相同的业务逻辑（和 DAL）。
• ...

没有那个就活不下去..