Web应用程序数据层dis / advantage

时间:2009-08-25 16:51:28

标签: c# asp.net web-applications

我想知道通过将我的业务逻辑和数据与我的Web表单分离来分层我的Web应用程序的长期优势(如果有的话)。 (即表单,业务逻辑,数据不在同一个文件中,但每个文件本身在另一个文件夹中的类本身或与其他类似的类组合)。我喜欢将所有内容尽可能地模块化并且有效地执行此操作似乎将所有代码保存在一个文件中 - 在Web表单中使组织和重用更容易。在整个站点中使用某些功能,例如管理将在其自己的类和文件中的连接。我对c#很新,对不起,如果我弄乱了这个术语。

由于

2 个答案:

答案 0 :(得分:4)

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

如果您的数据访问代码保存在单独的图层中,则可以轻松调整它以使用其他数据库。特定于数据库的代码将封装在此层中,而客户端将使用与数据库无关的接口。因此,此处的更改不会影响业务层实施。

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

如果您的代码干净且结构合理,则维护工作将保持较低。每当您需要更改某些内容时,您就会知道在何处找到负责任的代码,要更改的内容以及如何确保更改不会影响其余代码。

对于ASP.NET而言,不关注问题分离导致许多项目变成一个巨大的代码模糊 - 表示代码执行业务决策,代码隐藏在没有合适的业务方法存在的情况下直接与数据库进行对话,数据库得到从许多地方写入数据流遵循多条难以追踪的路径,未引入所有路径的一条路径的变化将破坏完整性并导致数据损坏=>结果?几乎不可维护的代码黑盒子,任何改变都需要越来越多的努力,直到它停止 - 项目“完成”。技术破产。

答案 1 :(得分:2)

我们通常按如下方式对应用程序进行分层(每个层都在解决方案的单独项目中,因此在一个单独的Dll中: 我总是会(第一个)有一个分层应用程序

  • 表示层(JUST UI和数据绑定逻辑)
  • 接口层到 业务层(定义 访问BL的合同
  • 业务层实施( 实际逻辑,数据验证等......)
  • 接口层到数据访问 图层(定义合同) 访问DAL)
  • 数据访问层 实施

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

优点如下:

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

没有那个就活不下......