问题标签 [n-layer]

在 N 层架构中，REST 接口暴露了一些资源。客户端需要使用基于 TLS 的基本身份验证进行身份验证。业务逻辑确保数据有效且系统可接受。应用过滤器以确保租户只能查看和更改他的数据。如果服务需要处理相同的数据，最好
1) 使用相同的 REST 接口，但应用服务级别过滤器并使用技术帐户进行身份验证
，或者最好
2) 使用服务帐户直接业务（域）层？`

您对使用其中一种方法而不是另一种方法的看法或逻辑是什么？

在以下示例中，AccountService和ProductService位于 ASP.NET MVC 应用程序中。AccountWebAPI和ProductWebAPI是外部托管的API微服务。

1) 我可以消除ProductService并在CustomerAccountController本身中编排订单的检索吗？这是因为我将控制器视为DDD（域驱动设计）中提到的应用层/服务。

2）我是否违反了n层架构，因为ProductService调用了同一层的AccountService ？

3）由于AccountWebAPI和ProductWebAPI是微服务，它们是否必须在客户端应用程序（MVC App）中分离为AccountService和ProductService以保持职责分离？所以ProductService需要重命名为ProductAppService并且ProductService应该与ProductWebAPI交互，就像AccountService与AccountWebAPI对话一样。

更新：我意识到OrderService将是订单的适当服务名称，而不是ProductService。

层：

视图 -- 控制器 -- 服务 -- WebAPIs -- 域 -- 存储库

OrderView -- CustomerAccountController -- ProductService（同层调用AccountService） -- ProductWebAPI -- ProductDomain -- ProductRepository

我正在开发一个 asp.net mvc 项目。我也想使用n层解决方案结构。所以，我正在为我的解决方案使用以下结构。它特别显示了我有疑问的解决方案的一部分。我计划为我需要的每个实体创建接口，以便在将数据（列表或对象）从 dal 传递到演示文稿时不重复代码并且不会出现问题。你怎么看？这是一个好方法吗？

[

我正在使用 ASP.NET MVC 应用程序并尝试将其移至 3 层架构。我不知道在哪一层放置身份数据？我应该创建两个数据库上下文（在两层内）还是从表示层引用 DAL？有人说PL和DAL之间不应该有引用。请给点提示好吗？

谢谢你的回答

我很难解释这个问题。但也许我可以在这里做得更好。

在我的 4 层架构应用程序中，一个带有仓库管理系统（一个简单的系统）但有很多业务规则的在线商店。

示例 1：

1. Presentation Layer调用Business Layer保存_Product
2. BL.SaveProduct方法调用然后DL.SaveProduct调用DL.DecreaseBalance方法

如果 中发生异常DL.DecreaseBalance，产品将被保存，违反业务规则，如果我不能通过让 DL 处理两个事务来违反 SoC

是否有设计模式或技巧来帮助解决这个问题？

我的 BL 方法

使用相同方法构建的示例 DL 方法

TransactionScope 不工作

我一直在尝试使用实体框架开发带有 WinForms 应用程序的 N 层设计。

下面的示例流程对于使用实体框架在 n 层设计中保存新记录是否正确？

1. 表示层

   A) UI 执行光屏输入数据验证。然后 UI 将视图模型转换为 DTO 并将其传递给应用程序层。

2. 应用层

   A) 应用层将 DTO 发送到领域层中的领域模型

3. 领域层

   A) 在创建域模型 SoftwareRequest 实体的新实例之前，验证符合业务规则的传入 DTO 值。

   B) 如果所有值都已验证，则创建域模型 SoftwareRequest 实体的新实例。

   C) 退出以将控制权返回给应用层

4. 应用层

   A) 调用基础设施层 SoftwareRequest Repository 并传入由域模型提供的新域模型 SoftwareRequest 实体

5. 基础设施层数据访问

   A) SoftwareRequest Repository 从应用层接收新的域模型 SoftwareRequest 实体。

   B) 将新的域模型 SoftwareRequest 实体添加到实体框架 DBContext - context.SoftwareRequests.Add(NewDomainModelEntity)

   C) 保存新实体 - context.SaveChanges()

   D) 退出以将控制权返回给应用层

6. 应用层

   A) 将保存操作的结果转换为 DTO

   B) 退出以使用包含添加新 SoftwareRequest 的结果的 DTO 将控制权返回给 UI

7. 用户界面

   A) 将收到的 DTO 转换为 View Model

   B) 在屏幕上显示视图模型数据，显示添加新软件请求的结果

--------- 以下信息于太平洋标准时间 2016 年 2 月 22 日上午 6:49 添加 ---------

依赖总结：

表示层 - 引用应用层来发出请求 - 引用域层仅用于使用描述 DTO 的接口，这些 DTO 将从 UI 发送或从应用层接收

应用层 - 引用描述 DTO 的域层接口。还使用域模型实体的接口定义，因此它可以将来自基础设施层的实体响应转换为返回给 UI 的 DTO。此处还引用了基础设施层数据访问，因此在涉及的域模型实体已通过域层验证规则和值之后，可以访问存储库以执行 CRUD 操作。

域层 - 没有对上面或下面的任何层的引用。没有来自任何层的依赖注入服务。这不包括涉及具有基础设施存储库的 CRUD 的任务。所有请求（例如规则验证）都会收到 DTO，其中包含执行请求的域任务所需的所有信息。

Infrastructure Layer Data Access - 引用描述域模型实体的域层接口，这些实体用于在存储库中执行实体框架操作（即 CRUD 操作）。还参考域层来定义存储库的接口，这些接口在基础设施层数据访问中实现。该层不使用 DTO。该层通常以域模型实体响应应用层。应用层将所有域模型实体响应（即 IEnumerable）转换为 DTO，然后发送回 UI。

在将数据从表示层中的用户界面传递到应用层然后传递到域层进行验证时，我对应该使用什么表单数据感到困惑。我正在通过 DTO，但我听说我不应该。相反，我应该只将原语和标量传递给域层。如果不使用 DTO 类结构，我不确定这是如何完成的。下面是我在 UI 中使用 DTO 的方式：

我的用户界面在屏幕上可能具有如下值：

产品名称： 产品ABC

产品编号：1234

描述：描述

当用户单击提交按钮将此记录添加到数据库时，我构建了一个 DTO，如下所示：

我将此 DTO 传递给应用程序层，然后传递给域层，在那里它读取值以验证并创建实体的新实例。

如果我不应该这样做，那么应该如何打包来自 UI 的值以供应用层接收并发送到域层以执行验证和创建新实体？

也许只是一个简单的数据结构？

（即 CreateNewProduct(aNewProductStructure) 而不是 CreateNewProduct(aNewProductDto) ？

提前致谢。

---------- 更新 2/24/2016 上午 9:58

好的，根据我忽略的最近信息，应用程序层似乎应该从 UI 接收 DTO，然后将其转换为片段以传递给域。因此，在我上面的示例中，应用层应该将要创建的新产品按如下方式传递给域层：

CreateNewProduct(ProductName, ProductCode, Description);

CreateNewProduct 的定义：

基本上，我应该将各个值传递给域。

我曾经在域层中声明我的 DTO。但那是在我后来理解应用层应该将原语传递给域层以实例化域模型实体而不是 DTO 之前。既然我知道了这一点，我就不需要在域层中声明 DTO。

由于我的应用程序层具有应用程序服务，可以将数据与 DTO 相互转换以将数据传输到各个层，因此我认为 DTO 也可以在应用程序层中声明。

那么，应用层通常是应该声明 DTO 的地方吗？

提前致谢。

更新：2016 年 2 月 25 日我将根据 .NET 应用程序架构指南第 2 版中的以下引用在应用程序服务层中为我的应用程序服务定义接口：“在服务层中，您定义和实现服务接口和数据合同”..

我有一个具有 4 层的 N 层 Winforms 应用程序，如下所示：

表示层

应用层

领域层

基础设施层

我的应用程序层有一个产品服务类，用于产品的所有存储库相关操作。

产品服务类的接口文件属于应用层还是领域层？我问是因为我的存储库的接口文件是在域层中定义的，即使它们是在基础设施层中实现的。

提前致谢。

我有一个业务规则要在域层中验证 Order 实体。该规则是请求客户必须在商店拥有至少 30 天的帐户才能获得特定折扣。30 的值可以定义为域层的订单实体中的常量，或者作为存储过程的一部分，其中它被定义为常量并在被应用程序服务调用时返回，然后传递给域实体进行规则验证？

如果是在存储过程中，那么我可以更改数据库中的数字并重新编译存储过程，这很容易做到，不需要其他人参与。但是如果我把它放在实体中，它就会成为应用程序代码的一部分，不仅需要重新编译，还需要重新分发。

对于试图实现 DDD 设计的 N 层设计应用程序，这些数字常量存储在哪里？