我正在为硬件安装（水循环系统）构建控制系统。我把它设计成两层：硬件描述层和控制层。

硬件描述层包含硬件图，描述管道如何连接到热交换器和其他设备。该层的数据可根据安装进行配置，并将在运行时读取。因此，硬件描述层中的所有类都应该以一种或另一种方式序列化（通过 Hibernate/序列化到 XML 左右）。

控制层将用智能装饰硬件描述层类，因此热交换器将获得一个与之关联的 HeatExchangerController。

在这个系统中，控制层中的实体可能需要通过硬件描述来寻找他们最近的邻居，所以热交换控制器可能会做类似的事情

问题是这使得较低层（硬件层）意识到它上面的智能（它的控制器）。这不仅打破了层之间的单向依赖规则，而且由于所有硬件描述类都应该是可序列化的，这使代码复杂化，因为对更高层的所有引用都需要是可选的，声明为瞬态的等。

现在，我有点难以确定通过这样的硬件描述层提供控件是一个好主意还是坏主意，或者是否有任何替代方法可以采用。我只能想到一种方法，它涉及镜像和委托几乎所有的硬件描述层，这似乎是一种很好的侵入方式。

所以我的问题是你们中是否有人认识到这种情况并有任何提示/经验。它有名字吗？是否有任何好的模式/最佳实践，是否有任何其他知名的库/框架也有并解决了这种情况？

谢谢你。

我在大学中将 Google App Engine 应用程序作为课堂项目。现在我需要对其进行优化以将其用于商业用途。

如今，代码非常慢。它只有几个模型，每个模型都有很多属性。在重写模型代码之前，我需要知道如果我增加模型的数量，我的应用程序是否会更快，即增加解耦。直到什么时候我应该考虑将模型划分为其他模型？

另一个问题，如果解耦对性能有积极影响，模型中的属性数量是否与从数据存储中获取它的时间成正比？

我有一个模型需要从辅助源加载外部数据。存在许多 Web 服务，我的模型可以从中获取数据（可交换），但我不想创建难以更改服务的代码（成本因可变和固定使用而显着不同，并且可能会发生变化将被要求）。

我想创建一个驱动程序来执行交互（如果服务需要切换，然后创建进一步的自定义驱动程序）。不幸的是，由于驱动程序和模型的紧密耦合，将代码提取到插件或 gem 中是没有意义的。我已将所有代码提取到一个模块中（参见示例），并且目前在我的模型上方声明了代码。

Rails (3.0.0) 是否有存储模块与模型紧密耦合的约定？我应该使用插件来做到这一点吗？这与“app/helpers”目录相关联吗？如果不是，最适合存储代码的位置在哪里？谢谢！

我有一个 ASP.NET MVC 2 项目。我已经解耦了层。我有一个服务层和一个存储库层。控制器调用服务方法，只有服务层调用存储库中的方法。

问题是：我的存储库类中的一个方法使用 LINQ 连接。通过这种方法，我想返回一个类型，合并来自连接表的一些数据。（即，Name = a.Name，Position = b.Position）而且我总是在我的存储库类中返回 IEnumerables。所以在这种情况下，我似乎需要为 (Name, Position) 定义一个新类型，并从存储库函数中返回该类型。但是，然后，我必须将该类重新映射到其他 ViewModel 类。（因为我正在分离关注点，我不应该在存储库中使用 viewmodel 类，对吗？）这会导致许多不同的类。EF 类、连接表的类和视图模型类。

我在正确的道路上吗？

请赐教。

谢谢

我正在阅读有关依赖倒置和解耦的理论，但我看不出两者之间的区别。

依赖倒置谈论解耦功能组件，以便更高级别的组件不依赖于较低级别的组件。

解耦谈论同样的事情以及如何实现它。但是后来我们有了IoC 容器，这让事情变得更糟了。为什么不将它们称为Dependency Inversion Containers甚至更好的Dependency Injection Containers，因为它们服务于独立组件的运行时耦合？

然后我们有控制反转。它基本上和依赖倒置是一样的，不是吗？为什么用三个词来描述同一个东西？还是我瞎了？

1. 三者有什么区别？
2. IoC 在 IoC 容器中必须做什么？

我有一个用 Java 编写的模块 - Web 服务模块，它接受请求处理它（这里有一些业务规则），在 db 中保存（修改或删除）值（使用 Hibernate），然后发送状态响应）。重构该模块是否合理，因此最终会有 2 个模块 - 1 是 Web 服务模块，2 - 应用业务规则和生成数据库流程的处理模块？如果是，那么模块之间信息交换的良好做法是什么？谢谢 ！

我有几个从 WSDL 生成的类，我需要编写 2 个小型应用程序来读取一些输入数据、调用 Web 服务并编写响应。

现在我创建了一堆非常简单的包装类，它们从 web 服务调用返回的对象中获取数据。我围绕 web 服务代理创建了一个包装器，它返回我自己的类而不是生成的类型。我试图瞄准的是一个解耦模型，它不会向我的简单应用程序显示任何生成的类。

但我想我可能会过度设计整个事情。目前这 2 个小型应用程序的大小与模型类和包装器的大小几乎相同，但我相信以后会有更多的需求出现，我想要灵活一些。

我应该隐藏生成的类（并将这部分视为数据访问层）还是应该使用第一个版本的生成类？

注意- 我已将原始帖子移至底部，因为我认为它对于该线程的新手仍然有价值。下面直接尝试根据反馈重写问题。

完全编辑的帖子

好的，我将尝试详细说明我的具体问题。我意识到我正在将域逻辑与接口/表示逻辑混合一点，但老实说我不确定在哪里分开它。请多多包涵 ：）

我正在编写一个应用程序，该应用程序（除其他外）执行物流模拟以移动物品。基本思想是用户看到一个类似于 Visual Studio 的项目，她可以在其中添加、删除、命名、组织、注释等等我将要概述的各种对象：

• 项目和位置是基本的无行为数据项目。

  /li>

• WorldState是项目-位置对的集合。WorldState 是可变的：用户可以添加和删除项目，或者更改它们的位置。

  /li>

• 计划表示在所需时间将项目移动到不同位置。这些可以导入到项目中或在程序中生成。它引用一个 WorldState 来获取各种对象的初始位置。计划也是可变的。

  /li>

• 模拟然后执行计划。它封装了许多相当复杂的行为和其他对象，但最终结果是一个SimulationResult，它是一组指标，基本上描述了这个成本和计划的完成情况（想想项目三角）

  /li>

基本思想是用户可以创建这些对象，将它们连接在一起，并可能重复使用它们。一个 WorldState 可以被多个 Plan 对象使用。然后可以在多个计划上运行模拟。

冒着非常冗长的风险，一个例子

问题是当这样的事情被执行时：

因此，基本上当用户尝试通过world.RemoveItem(item)调用从 WorldState（可能是整个项目）中删除项目时，我想确保在使用该 WorldState 的任何 Plan 对象中都没有引用该项目。如果是，我想告诉用户“嘿！下面的 X 计划正在使用这个项目！在尝试删除它之前去处理它！”。我不希望world.RemoveItem(item)通话的那种行为是：

• 删除项目但仍让计划引用它。
• 删除项目但让计划静默删除其列表中引用该项目的所有元素。（实际上，这可能是可取的，但仅作为次要选项）。

所以我的问题基本上是如何以一种完全解耦的方式实现这种期望的行为。我曾考虑将其作为用户界面的权限（因此，当用户在某个项目上按下“del”时，它会触发对计划对象的扫描并在调用 world.RemoveItem(item) 之前执行检查） - 但是（a）我我还允许用户编写和执行自定义脚本，以便他们可以调用world.RemoveItem(item)自己，并且 (b) 我不相信这种行为是纯粹的“用户界面”问题。

呸。好吧，我希望有人还在阅读...

原帖

假设我有以下课程：

因此，假设存在一个约束，即 Spaceship 的大小必须小于或等于其 Home 的 MaximumShipSize。

那么我们该如何处理呢？

传统上我做了一些这样的耦合：

对于像这样的简单示例（因此可能是一个坏示例），这是可以管理的，但是我发现随着约束变得越来越大，越来越复杂，并且我想要更多相关的功能（例如，实现一个方法bool CanChangeMaximumShipSizeTo(double)或其他方法来收集太大的船）我最终编写了更多不必要的双向关系（在这种情况下 SpaceBase-Spaceship 可以说是合适的）和复杂的代码，这在很大程度上与等式的所有者无关。

那么这种事情一般是怎么处理的呢？我考虑过的事情：

1. 我考虑使用事件，类似于 ComponentModel INotifyPropertyChanging/PropertyChanging 模式，除了 EventArgs 将具有某种 Veto() 或 Error() 功能（很像 winforms 允许您使用密钥或抑制表单退出）。但我不确定这是否构成事件滥用。

2. 或者，通过明确定义的接口自己管理事件，例如

asdf 我在这里需要这一行，否则格式将不起作用

但我不确定这是否更好。我也不确定以这种方式滚动我自己的事件是否会对性能产生一定的影响，或者还有其他原因导致这可能是一个好/坏的主意。

2. 第三种选择可能是使用 PostSharp 或 IoC/依赖注入容器的一些非常古怪的 aop。我还没有准备好走这条路。

3. 管理所有检查的上帝对象等等 - 只是在 stackoverflow 中搜索上帝对象给我的印象是这是坏的和错误的

我主要担心的是这似乎是一个相当明显的问题，我认为这是一个相当普遍的问题，但我还没有看到任何关于它的讨论（例如 System.ComponentModel 没有提供否决PropertyChanging 事件的设施 - 是吗？）；这让我担心我（再次）未能掌握耦合或（更糟糕的）一般面向对象设计中的一些基本概念。

评论？}

这可能有点模糊，但我正在开发一个程序，其中有几个更新 UI 的类。我创建了一个“中间人”类，它基本上接受所有 UI 请求（除其他外）并将它们路由到 UI 本身，这样 UI 类只与中间人交互。

问题是 UI 类在其界面中有大约 20 个不同的函数，而我的中间人类所做的基本上就是从较低级别的类中调用，然后在 UI 中调用一个基本相同的函数，这让我想知道是否这在某种程度上违背了整个目的。我相信这是一个经常出现的问题。有没有更优雅的方法来做到这一点？

谢谢，

下午

为了使 OO 系统尽可能地解耦，我正在考虑以下方法：

1）我们运行一个 RMI/目录之类的服务，对象可以在其中注册和发现彼此。他们通过接口与该服务对话

2）我们运行一个消息服务，对象可以向其发布消息，并注册订阅回调。同样，这通过接口发生

3）当对象A要调用对象B的方法时，通过上面的#1发现目标对象的唯一标识，并在消息服务上为对象B发布消息

4) 消息服务调用 B 的回调来给它消息

5) B 处理请求并在消息服务上发送对 A 的响应

6) A 的回调被调用并得到响应。

我觉得这个系统尽可能地解耦，但它存在以下问题：

1) 通信通常是异步的

2）因此它不是实时的

3）整个系统效率较低。

是否还有其他实际问题明显不适用于这种设计？你对这个设计有什么看法？