在业务或数据层编写逻辑答案

【问题标题】：Writing Logic in Business or Data Layer在业务或数据层编写逻辑
【发布时间】：2014-02-28 02:08:02
【问题描述】：

我在我的 Web 应用程序中使用了三层架构。我正在数据层中编写所有与 MS SQL Server 数据库相关的代码，现在需要从 Excel、CSV 和其他电子表格文件中读取大量数据。我正在使用 OleDbConnection、OleDbCommand、OleDbDataReader 从用户上传的电子表格文件中读取所有内容。关于我应该在哪里编写所需的代码存在争论，在业务逻辑层还是数据层？我的假设是因为 从电子表格中读取 与我们的 MS SQL Server Db 没有任何关系，所以我想在业务逻辑层中编写它。

这是一个正确的决定吗？有什么想法吗？

【问题讨论】：

为什么不在业务层中抽象来源和使用合同？这将使其可测试并独立于数据层。

标签： c# .net design-patterns architecture

【解决方案1】：

数据层。实际上它仍然是一个数据流。你应该这样对待它通常，您的业务层甚至不应该知道数据来自哪里。

【讨论】：

【解决方案2】：

我宁愿您为什么不在统一的数据访问层的解决方案中构建多个项目。从理论上讲，您仍将设计一个三层架构，但具有高可管理性和可扩展性的代码差异。下面是架构树的样子：

应用逻辑 [表示层]
业务逻辑层
数据访问层 [与 BL 通信的抽象层]
- SQL Server DAL
- Excel DAL
- 访问 DAL
- 任何其他 DAL...

我相信这将适用于您的架构。

【讨论】：

【解决方案3】：

从任何来源提取或保存数据的最佳选择是在数据层中实现它。然后将此数据传递给业务层以应用业务逻辑/业务规则。保持数据访问和存储对业务层透明。

一些好处： 1.这是为了将未来的可扩展性和可扩展性解耦。如果您需要将 excel 数据源更改为 RDBMS 或任何其他类型的文件，则无需更改任何业务逻辑。只有数据访问逻辑会改变。同样，如果您需要添加更多业务规则或删除一些规则，则无需更改数据访问层。 2. 如果您需要合并来自两个数据源的数据，那么您可以轻松地对业务层透明

【讨论】：