C#中的三层应用程序-将数据和业务模型放在哪里

本文关键字：数据 业务 模型 在哪里 应用程序 三层 | 更新日期: 2023-09-27 17:58:26

我正在C#中构建一个标准的三层应用程序

1前端控制台应用程序/但我可能会将其更改为ASP.NET MVC网页

2业务逻辑层

3使用连接到SQL数据库的实体框架的数据层/但这可能会更改为windows azure

主要目的是显示一些客户数据。

存储在数据库中的客户具有以下字段-

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Creationdate
Updatedate
IsDisabled //this represents "deleted" customers i.e. the app will never use deleted customers, but I want to keep them in the database anyway

在中间层，我只想要

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Updatedate

在第一个应用程序的前端，我只显示

CustomerID
Firstname
Lastname
DateOfBirth

从从数据层加载客户（可能会改变）并在中间层和演示层使用该客户（可能改变）的角度来看，我如何正确实现n层应用程序？

我应该把客户模型放在哪里？我需要不止一个吗？我需要一个ICustomer接口吗？

项目详细信息该项目将由两个团队开发，一个位于美国，另一个位于东欧，将有四到五名团队成员。

有一个遗留的数据访问层，这个项目将不会使用。相反，我们将建立一个新的实体框架；我们需要设计和构建一个将在所有新应用程序中使用的数据层（对于这个应用程序，我们只需要客户表和一两个表）。其他项目将向该层添加其他表。

我正在使用DI注入ICustomerDepository（请参阅此SO问题）。但将实现存储库和工作单元模式。

我关心的是如何适当地分离图层。在接下来的几个月里，我们将添加许多新项目，新的数据层将快速增长。我们也在考虑在某个时候转移到Azure，所以我希望能够交换实体框架数据层，而不必重写业务层和前端层。

C#中的三层应用程序-将数据和业务模型放在哪里

您有一个数据模型（DB模式）、一个域模型和一个视图模型。

如果您的目标是解耦层，那么在这三个层中的每一个层中都应该有代表Customer的不同类（但请参阅@Joe在评论中提到的文章）。

您的数据访问技术将推动数据模型到域模型的映射。如果使用实体框架，它提供了在这两个模型之间进行映射的能力。

要将域模型映射到视图模型，请查看Automapper，以便在域对象（例如业务对象）和视图模型之间进行映射。

更新

根据你的新信息，我会分享我会做什么。这肯定不是唯一有效的方法。

考虑到一个分散的团队，明确的责任线很重要。不同的人，在不同的时区，有不同的团队领导，将在代码上工作。

考虑到新软件是建立在遗留数据库上的，您必须注意三个事实：

  • 要改变旧数据库以适应新软件的需要并不容易
  • 新软件不应该因为现有数据库的结构而固有地具有次优设计
  • 您构建的下一个应用程序可能需要会污染当前应用程序设计的数据

我会做以下

  • 创建表示旧数据库结构的数据传输对象（DTO）
  • 使用Repository和Unit of Work Patterns为业务对象层提供对DTO的访问
  • 根据应用程序的需要设计业务对象层（中间层，其类通常称为实体）。不要污染基于DTO的结构（最终是遗留DB的结构）的对象设计
  • 使用诸如Automapper之类的技术来简化在这两个图层之间进行映射的管道工作
  • 创建表示给定UI屏幕（MVC术语中的View）将处理的数据的UI对象（MVC术语称为Models）
  • 根据UI模型与业务对象（实体）的对齐程度，您可能希望使用Automapper，或者只希望在自定义代码中填充它们

同样，考虑到我的背景、经验和偏好，我会这样做。这不是唯一有效的方法。

相关文章：