问题标签 [multi-tier]

我继承了一个 n 层应用程序，我想对它的文件分组方式进行一些解释。

我猜 BAL 是业务访问层 DAL 是数据访问层

EAL有什么猜测吗？有人知道EAL是什么吗？

另外，为什么 BAL 中的文件名内容与 DAL 相同？

干净和n 层架构之间有什么区别？

我需要在 C# 中通过引用传递 this 对象。但如您所知，这是不可能的。我有一个多层应用程序。简而言之，DAL 从 Web 服务中获取 JSON 格式的数据。JSON 数据必须在业务层对象中进行转换。因此，我初始化了业务层对象并将其传递给 DAL。DAL 会将数据转换为对象。我展示了一个代码示例。首先是 DAL：

现在业务层正在使用这个 DAL 类：

所以问题是，不可能发送“this”作为参考。所以我看到的解决方案是创建一个复制对象并将其发送到 DAL，然后将其值分配给 this 对象。但这不是一个聪明的解决方案。有没有办法在 C# 中解决这个问题？

我有一个 n 层应用程序，而核心 Web 服务是使用 Web API 构建的。许多 Web 服务的方法设置为 HTTPGET 并接受 DTO 对象作为参数。我使用 MVC 5 构建的客户端应用程序正在使用 HttpClient 调用此 API。

所以似乎通过使用 client.PostAsJsonAsync() 我可以传递一个对象，而 client.GetAsync() 不允许我这样做。这迫使我在 URL 中明确指定 DTO 的属性，这可行，但似乎有点多余。

有人可以通过 GET 调用解释为什么这不可能并提出更好的做法吗？

我作为一个团队的一员在一些 3 层应用程序上工作了相当长的时间。我喜欢这种架构，但在所有这些应用程序中，我注意到最顶层的两层对数据抽象层的严重依赖。这使得测试和模拟变得困难，因为如果没有与非常大的数据库的现有数据库连接，几乎不可能运行应用程序或执行某些方法。有没有试图解决这个问题的模式？

我需要在两层上安装 MS Dynamics CRM 2013。我有两个虚拟机，我想在一个实例上安装 CRM 的数据库，在另一个实例上安装 CRM 的应用程序。

请指导我如何做到这一点。

问候，

F.阿里

在阅读了关于 stackoverflow 的一些 Q/As 之后，我仍然对在我的 Web 应用程序中正确实现 DTO 感到困惑。我当前的实现是一个（基于 Java EE）多层架构（具有持久性、服务和表示层），但所有层都使用一个“通用”包，其中包含（以及其他）域对象。在这种情况下，这些层实际上不能被认为是独立的。我打算逐步删除 common 包，但我遇到了各种挑战/问题：

• 假设持久层将使用类myproject.persistence.domain.UserEntity（一个基于 JPA 的实体）来将数据存储到数据库或从数据库加载数据。为了在视图中显示数据，我将提供另一个类myproject.service.domain.User。我在哪里转换它们？用户的服务是否负责在两个类之间进行转换？这真的有助于改善耦合吗？
• User类应该是什么样子的？它应该只包含不可变的吸气剂吗？视图编辑现有用户（创建新User，使用现有User对象的 getter 等）会不会很麻烦？
• 我应该使用相同的 DTO 类（User）向服务发送请求以修改现有用户/创建新用户还是应该实现其他类？
• 通过使用myproject.service.domain中的所有 DTO，表示层不会非常依赖服务层吗？
• 如何处理我自己的异常？我当前的方法会重新抛出大多数“严重”异常，直到它们被表示层处理（通常它们被记录并且用户被告知出现问题）。一方面，我有一个问题，我再次拥有一个共享包。另一方面，我仍然不确定这是否可以被视为“最佳实践”。有任何想法吗？

谢谢你的任何答案。

这个问题可能不像你想象的那么重要。首先，感谢您的阅读。我是一名计算机科学专业的学生。我刚刚开始了解 AWS，尤其是 Route 53，所以如果有任何伤害您的眼睛，请原谅我 :)

我们都知道，Amazon Route 53 为客户提供了跨多个可用区和区域将用户路由到 EC2 实例、S3 存储桶和弹性负载均衡器的能力，并且有不同形式的 DNS 负载均衡，包括：

• LBR/基于延迟的路由，路由到延迟最低的区域
• WRR/加权循环，为不同的目标分配权重

此外，结合两者的用户指定配置也是可能的 (LBR+WRR)。

Route 53 的灵活性使用户能够节省成本，但是对于最终用户而言，手动配置可能变得越来越复杂。寻找最佳的非概率策略（例如 WRR 权重）是 NP 完全的。

我们需要为服务器 IP 地址赋予不同权重的可能情况是什么？鉴于可以有跨多个可用区的 EC2 服务器，并且实例可以同时包含前端和后端，或者仅包含应用程序层或数据库？有没有什么想法可以更好地结合其他 AWS 服务使用 Route 53，以提高交互式多层云应用程序的性能？

很抱歉这个冗长的问题。我正在寻找有关尝试更好地使用 Route 53 以及结合其他 AWS 服务以实现多层云应用程序的最佳方式/起点的想法和想法。不一定是 100% 正确的答案。欢迎任何想法或建议。提前谢谢了 ！

更新：

我可能应该重新表述这个问题：在 Route 53 中（即在 DNS 服务中）设置加权记录的目的是什么？显然，DNS 中的 WRR 可以控制部分流量，但如果我们仅仅依靠这种 DNS 负载平衡（或负载分配），我们将把繁重的工作负载放在许多其他 DNS 服务器上。我可以想到的一种情况是，像 google 或 Facebook 这样的网站可能会获得大量的域名查询，WRR DNS 负载平衡可能很有用，并且必须存在某种会话粘性，因为跨服务器共享会话似乎是一种馊主意。

在 Route 53 中使用加权记录是否有任何其他方式/目的。

非常感谢您考虑我的问题！

我目前正在评估重构驱动程序管理的替代方案。

在我的多层架构中，我有

基类

• DAL.Device//我的实体

接口

• BL.IDriver//处理应用程序和设备之间的数据处理
• BL.IDriverCreatorIDriver//从a创建一个Device
• BL.IDriverFactory//处理驱动创建请求

的每个专业化Device都有相应的IDriver实现和相应的IDriverCreator实现。

目前，映射是通过业务层 / 中的类型检查修复的DriverFactory。这意味着每个新驱动程序都需要 a) 更改其中的代码DriverFactoryb) 引用新的IDriver实现/程序集。从客户的角度来看，这意味着每个新驱动程序，无论是否使用，都需要对其硬件环境进行复杂的重新验证，因为这是一个关键过程。

我的第一个灵感是使用像 nameconvention 这样的 caliburn micro

请参阅Caliburn.Micro：Xaml 变得简单

• BL.RestDriver

• BL.RestDriverCreator

• DAL.RestDevice

在收到RestDevice内部文件后，IDriverFactory我可以通过反射加载所有驱动程序 dll 并进行名称拆分/比较（从 xxDriverCreator 和 xxDevice 中提取 xx）

另一个想法是自定义属性（这也导致比较字符串）。

我的问题：这是层边界之上的好方法吗？如果没有，什么是好的方法？

我是一名申请 ASP.NET 工作的 PHP 程序员。他们给了我一个任务，让我制作一个（我选择的）实现多层架构的应用程序。

我有很多难题。据我了解，多层是一个没有通用形式的概念，每个人都应该决定什么是最适合他们的。但是，他们建议我表示层不应该对数据访问层有任何引用，这是有道理的。但...

我创建了一个新项目Add new project（具有控制器和视图），它是一个表示层。现在，在表示层中，还有一个class library使用 Ninject 为整个应用程序注入依赖项的NinjectIoC. NinjectIoC 必须具有对表示层项目的引用，以便将依赖项作为参数直接注入控制器中。它还必须具有对所有其他层（DataAcessLayer、BusinessLayer 等）的引用，以便将它们绑定到它们的依赖项。

主要问题是表示层项目还必须具有对 NinjectIoC 的引用才能在 Global.asax 中创建 StandardKernel，这会创建循环依赖，并且是不允许的。

唯一的解决方案是添加对所有层（包括 DataAccessLayer）的表示层项目的引用，据我所知，这是一件坏事。但是，这是绑定所有层的所有接口并在 Global.asax 中执行的唯一方法。

我想错了吗？

编辑：

NinjectIoC安装了 Ninject 并引用了所有层，以便在应用程序中绑定它们。它必须具有对 UI 的引用才能在 Global.asax 中调用

UI 必须有一个引用，NinjectIoC以便它可以在 Global.asax 中调用它以进行控制器绑定。

我试图创建一个引用 NinjectIoC 的中间类库。UI 中引用了该库。问题是这也创建了一个循环依赖，因为 NinjectIoC 必须具有 UI 的引用才能绑定控制器。