在业务或数据层编写逻辑

时间:2014-02-27 05:57:21

标签: c# .net design-patterns architecture

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

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

3 个答案:

答案 0 :(得分:2)

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

答案 1 :(得分:1)

我宁愿为什么不在解决方案中为统一的数据访问层构建多个项目。从理论上讲,您仍将设计一个三层架构,但代码差异很大,可实现高可管理性和可扩展性。以下是架构树的外观:

  1. 应用程序逻辑[表示层]
  2. 业务逻辑层
  3. 数据访问层[与BL通信的抽象层]
    • SQL Server DAL
    • Excel DAL
    • 访问DAL
    • 任何其他DAL ......
  4. 我相信这对你的架构很好。

答案 2 :(得分:0)

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

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