问题标签 [multi-tier]

我为 Gradle 创建了一个插件，以部署到我公司的 OpenVMS 目录结构中，该目录结构添加deployDev、deployTest，并且在提供凭据时，将deployProd任务添加到应用程序构建中。我已将所有环境的配置文件提取到一个单独的项目中，以便我们可以将配置与应用程序分开部署。

这些自定义任务取决于应用程序插件的distZip任务，我还没有找到一个好方法来根据调用的任务（例如，deployDev包括开发配置）将适当的配置文件放入 zip 中。

我尝试在配置阶段让 deploy* 任务复制配置文件：

由于在所有任务上执行配置阶段，这不起作用，因此即使我们执行deployDev，测试配置也已复制到开发资源上。

我也试过：

然而，有了这个提议，distZip任务总是是最新的。有没有正确的方法来做到这一点？

我有一个三轮胎架构的应用程序。而且我不明白如何在这种情况下处理异常。我收集了一些问题：

1. 我是否需要创建一个通用异常，例如PersistentException，并使所有 DAO 类方法仅抛出一种类型的异常 - PersistentException？即在每个 DAO 方法（CRUD）中都这样做：

2. 可以为每个EJB 服务创建一个异常类（每个 EJB 接口一个异常）吗？

即假设我有一个 EJB bean，例如PersonManagementBean, OrganizationManagementBean，EmployeeManagementBean具有相应的@local和@remote接口。它们暴露给客户端，即实际上它们是会话外观（因此它们位于服务层）。所以为每个 bean ( PersonManagementException, OrganizationManagementException, EmployeeManagementException) 创建相应的异常类是个好主意吗？

或者最好只调用一个异常ServiceException（如 DAO 的情况）？

3. 什么类型的异常可以抛出我的服务（繁忙）级别（通常情况下）？我可以将 DAO ( PersistentException) 异常传播给客户端吗？IE

或者我需要将所有异常（在常见情况下）重新抛出为特定于服务的异常？

• “在一般情况下”我的意思是我知道在某些情况下，某些方法可能会抛出带有一些有用信息的额外异常（例如ValidationException有关哪些对象未通过验证规则的信息）

我不知道如何正确管理 C# 中的接口。我的目标是为我的业务层服务创建一个抽象类，该类具有一些通用方法（如 Save()、Dispose()），它们调用不同的 DAL 存储库方法。我希望避免在我的所有服务中重复以下内容：

我有一个类似的场景：

界面

达尔

提单

我也试过这个：

我知道我可以在接口中定义我想使用的所有方法，但是我将不得不处理泛型类型的很多问题，而且，正如你应该从我的问题中理解的那样，我在 C# 和我希望避免复杂性是可能的，至少我会更专业:)

对应用程序的每一层（即 、 等）都有一个例外被认为是一种很好PresentationException的ServiceException做法PersistenceException。但是如果我的服务层直接调用 DAO 方法（持久层的方法）而不需要额外的操作怎么办。

像这样：

我应该用一个块包装这个 DAO 方法调用try-catch并将可能的异常重新抛出为ServiceException？每个 DAO 方法都应该只抛出PersistenceException吗？

我正在开发一个实现多层模式的应用程序，其中 MySQL 用于持久性。有一个 WCF 服务提供对数据的访问并提供 DTO。

此外，我计划实现以下模式： - DTO - MVP（尚不确定是被动视图还是监督控制器） - 在适用的情况下针对接口编写代码

目前，我原始具有以下项目结构：

外框是 Visual Studio 中的项目文件夹。内盒是 C# 项目

在我继续编码并花更多时间在实际实现之前，我只是想获得一些关于我项目的结构/架构的反馈。

我正在思考以下问题：

1. 上述结构是否符合“最佳实践”？例如。接口、DTO 的位置
2. 可以有两个业务层还是将业务层拆分为客户端和服务器？服务器 BLL 旨在提供会话管理和安全等通用功能，而客户端 BLL 提供服务访问。它还控制其演示者的视图。
3. 服务器端目前不知道域对象。在这里也使用它们会更好吗？这将导致我的实体映射到域对象，然后映射到 DTO
4. 从 WCF 服务接收 DTO 是常见的还是我应该使用域对象（我知道这里已经讨论了很多，但据我了解，如果域对象不是那么复杂并且可以节省映射和编码，它将适用更改我的域对象和数据库时需要努力）这会不会导致非常难以维护的通信链，例如：实体<->域对象<->DTO<->域对象
5. 你把验证放在哪里？我想将基本验证放入视图或演示者中（例如，格式化、null/not null 值，......），而主要验证进入域对象......？
6. 在数据库中创建新记录时，假设是一个新用户，客户端是否也应该将新的 DTO 传递给服务器，还是创建一个接受简单数据类型（如字符串和 int）的服务方法更好？

很抱歉这篇长篇文章，但我认为最好将我的问题合并到一篇文章中并在其中提供项目结构。

提前感谢您的任何回答。

问候

我有一个具有以下组件的多层控制台应用程序： - 数据访问层 - 域层 - 使用数据访问层中定义的数据存储库类 - 引擎 - 这包含应用程序的入口点并使用域层类，编排操作

数据访问层类和领域层类实现了一组接口。你如何建议我做 DI？我是否需要在我的域类和引擎类中都引用 Ninject，有没有其他方法可以在一个地方进行绑定？这样做的最佳模式是什么。

我刚开始使用 DI 和 Ninject，所以任何帮助、示例和解释都会非常有帮助。

如何在运行时从另一个单元访问我的远程数据模块 (RDM) 的实例？（RDM 是单实例）。当我创建一个普通的数据模块后代时，Delphi 在同一单元中为它创建一个变量（例如：MyDM: TMyDM），但是当我创建一个 RDM 的后代时，没有变量。

我正在尝试将在运行时在另一个单元中创建的 TClientDataSet 的提供者设置为我的 RDM 中的 TDataSetProvider，但我找不到对我的 RDM 实例的引用。

我也尝试在设计时这样做，但是虽然将 TSQLQuery 的连接属性从同一单元设置到该 RDM 中的 TSQLConnection 没有问题，但我无法设置 TClientDataSet 的提供程序，因为没有来自RDM 出现在 TClientDataSet 的提供者列表中。

我一直在阅读有关使用asp.net-identity 的各种其他问题，但是当项目分层开发时，我没有看到任何关于将它与现有数据库一起使用的具体内容。为了论证的缘故，说以下是正确的：

• 解决方案
  • 网页界面
  • 服务
    • 用户服务
  • 数据
    • MyDbContext
  • 核
    • 用户

如何指定User（来自Core项目）作为IUserStore新身份提供者的身份？我是否遗漏了什么，或者这一切都假设网站和会员数据库始终位于同一个项目中（或者Microsoft.AspNet.Identity.*在模型所在的任何地方都有对库的严格引用）？

在 WebUI 层设置 DbContext 仅用于身份验证（并将其与服务绑定到“MyDbContext”）似乎很麻烦。我是否遗漏了什么，或者团队只是计划将其仅用于简单的应用程序？

反馈将不胜感激。

更多信息

如果值得一提：

• 这将是一个全新的解决方案；我没有旧的/现有的aspnet_*或webpages_*表担心。我正在尝试采用其他各种自定义解决方案并将它们与一个可靠的解决方案联系起来，所以我对很多选择持开放态度。但是，我想按层分解（如果可能的话）。

我有一个在 Tomcat 中运行的整体 Java 应用程序（前端/服务）。我正在尝试提出一种设计，使我能够将应用程序的所有部分作为单独的层缓慢迁移到（一个或多个）Akka actor 系统。作为第一次重新设计，我想在 Tomcat 中保持面向客户端的前端，并在 Akka 中重写一些中间层逻辑。

我有几个关于如何进行重新设计的问题：

• 前端与 Akka 通信的最有效方式是什么？我正在考虑 REST，但我想知道是否有更快的方法；
• 在 Akka 中重用现有的 JPA/hybernate 实体模型有多难？我正在寻找文档/陷阱。

谢谢

将 DTO 对象传递给服务层不是不好的做法吗？

现在我的服务层方法如下所示：

从 DTO 到业务实体 (MyEntity) 的映射值在表示层上完成

但我想将方法​​签名更改为：

之后，从 DTO 到业务实体的映射将发生在服务层。

编辑：我想要它，因为从 DTO 映射到业务对象时我需要打开休眠会话，因此实体上的所有更改都将自动刷新。