问题标签 [decoupling]

还有哪些（除了 IoC 和依赖注入）解耦模式和实践可以在对象内部使用，而不是在对象之间（在项目中）。

如果您可以在 Java 中发布任何示例，那就太棒了。

我正在使用弹簧，我遇到了豆子无法切割它的情况。所以我只想看看其他选择。主要是集成了第 3 方 API，这些 API 在 OOP 方面几乎没有考虑。一些 API 代码的可重用性非常糟糕。

这是当前的依赖关系图（TheTXI带有手绘圆圈）

游戏有玩家和他们之间共享的单个棋盘。玩家还可以访问棋盘，以便能够从中添加/移动/移除单位。玩家可以访问其拥有的单位，无论是在棋盘上还是棋盘外（一个单位也知道它的所有者，但可能可以将其删除并进行查找）。板上有单位并且知道单位的位置。单位有能力（玩家可能也有）

我无法弄清楚的最大问题是单位的能力。他们应该能够影响游戏中的任何东西，治疗/伤害玩家/单位，重新定位棋盘上的东西，甚至可能是游戏本身（目前还没有必要，但它可能会出现）。

我怎么能拥有可以影响任何事物的能力，而他们却没有对所有事物的参考？我意识到每个能力都可以而且应该只引用它需要的东西，但是一个单位类有内置的能力，所以如果一个单位的能力影响董事会，它需要以某种方式从单位获得对董事会的引用？

我试图让设计尽可能灵活，因为规则还没有一成不变（我们正在创造一个游戏，而且还很早，所以它尝试一些东西，看看感觉如何，改变规则直到游戏感觉正确）

即使是否有棋盘/地图仍然悬而未决，所以单元应该与它们当前的解耦。没有全局状态或任何“上帝对象”（还），我想保持这种状态。

特别是在 Python 和 webapp 中，所以虽然问题本身与语言无关，但当然欢迎任何基于具有一流功能的动态语言的细节。

对于依赖注入，我知道我必须将一个类的实例传递给主实例，而不是主类创建它自己的实例，就像这样（php）：

这一切都很好。我知道由于 Class_Two 和 Class_Three 都实现了 An_Interface，因此它们可以在 Class_One 中互换使用。Class_One 不会知道它们之间的区别。

我的问题是，不是将实例传递给 setOtherClass，而是传递一个诸如“Class_Two”之类的字符串，并让 Class_One 的 setOtherClass 方法像这样实际创建实例本身，这是否是一个好主意：

这种破坏依赖注入的目的，还是完全有效？我认为这种类型的设置可以帮助我进行配置，用户可以在前面指定他想在字符串中使用哪个类，然后可以将其传递给 Class_One..

实际上，写出来让我觉得这可能不是一个好的解决方案，但我仍然会发布这个，以防有人能给我一些关于为什么我应该/不应该这样做的好的反馈。

谢谢 =)

瑞安

早上好。

我不是受过教育的计算机科学家，所以请忽略任何可疑的术语滥用。

在我的框架中，名为 Record 的基本表单以对话框形式打开 RecordDetail 表单。例如，RecordClient 扩展 Record 并包含客户端数据和与客户端相关的子数据的选项卡式列表，RecordDetail 扩展一个子数据行以进行详细编辑，完全基于存储为用于 DataContext 的自定义属性的反射和显示覆盖。Record 是应用程序的子类，但我认为不需要子类 RecordDetail。除了在列出的子项中显示外键编辑外，此方法有效。

我必须使用ObjectListView和 Linq；我不能使用 WPF/XML。因为我为非连续数据库连接使用序列化技巧，所以当我克隆数据以管理状态时，我会丢失外键对象。ObjectListView 需要外键对象来显示和一般邪恶。我知道 Hibernate，但 Linq 让我不知所措：

在 RecordDetail 对话框关闭后，我如何从 Record 中访问外键对象 - 无需耦合框架和特定于应用程序的类？

那是，

其中“PrimaryKey”包装了主键属性，失败发生在“GetTable”、“Where”和“SingleOrDefault”之间。

在这个晴朗的星期天早上，任何观点都值得赞赏。

我在 Ruby on Rails 应用程序中有以下情况：

• 用户填写表单（评论），可以看到一个omniauth 页面，她可以在其中选择身份验证方法（openId、Twitter、Facebook 等）。
• 填写omniauth，成功后用户返回，获取会话并处理初始表单数据（发布评论）。

我都在工作，除了我的逻辑散布在我认为的丑陋方式中；SessionsController现在创建关于成功认证的评论。

什么是解耦这样的事情的好方法？模块是否应该Comment挂钩（监听）SessionsController？或者 SessionsController 是否应该简单地调用CommentsControllerorComment类上的一些方法来保存对成功身份验证的评论？是否有任何我可以让自己熟悉的模式来解决这些问题？

假设我有一个使用 IoC 实现数据访问库的业务对象库。我应该在哪里定义数据访问接口？它属于哪个图书馆？还是应该在一个单独的库中仅用于接口？

我认为，一种理想的方式是 CSS 只处理文档的表示方面，因此 CSS 和 Javascript 是解耦的，这是一个非常干净的解决方案。我们可以更改任何 CSS 或任何 Javascript 而不会破坏另一个。

但是如果我们实现花哨的用户界面，比如搜索框中的灰色单词，一旦用户在框中点击就会消失，这种行为呢？在这种情况下，CSS 和 Javascript 是非常耦合的，更改 CSS 会在某些地方影响 Javascript，并且很难处理，因为在一个项目中，可能有 5000 行 CSS 和 8000 行 Javascript，并且需要逐个搜索其他的下来并将它们一起更改可能会使其出现故障且难以维护。有没有更好的方法或方法让它更干净？

我有一个结构如下的解决方案：

• 模型组装
• 数据组装 - 定义存储库接口和基本存储库类
• ORM 程序集 - 实现存储库接口并继承基本存储库类 ^
• 业务组装 - 引用数据组装，并通过 MEF 动态拉入 ORM 对象（不显式引用 ORM 组装）
• UI 程序集

以这种方式，如果我们决定使用其他东西，我可以轻松地更换 ORM。

我很好奇 Unity 是否可以提供类似的功能。我想将我的业务逻辑与底层 ORM 分离。根据我的阅读，统一主要在编译时工作，而 MEF 在运行时工作。话虽这么说，是否有可能以这样一种方式与统一解耦，即我的业务层没有对 ORM 的引用，而只是它从数据组装中实现的接口？Unity 如何在不引用实现程序集的情况下定义实现接口的内容？

目前，对于 MEF，没有任何程序集引用 ORM（除非业务层在运行时动态将其拉入以发现部件并用对象填充接口）。我更愿意继续沿着这些思路工作，并想知道我是否可以使用 Unity 做到这一点。

我目前的申请结构是：

• 模型组装
• 数据组装
  • 定义由 ORM 实现的存储库接口
• ORM 组装
  • 从数据组装实现存储库接口
  • 使用统一（IoC 容器）注册Data.IRepository<>到ORM.GenericRepository<>
• 商务组装
  • 引用数据和模型程序集
  • 使用统一来解决类型IRepository<>
• 界面组装
  • 引用业务程序集

这种结构从本质上将业务层与实现IRepository<T>.

这种解耦结构的好处之一是我应该能够相对轻松地替换 ORM - 例如，从实体框架迁移到 NHibernate 或只是升级现有的 ORM。我目前首先使用 EF 4.1 代码，并且正在为 NHibernate 构建另一个程序集。

我正在考虑实施工作单元模式。

我读过这个模式应该在业务层中使用（在我的数据程序集中定义接口，并在 ORM 程序集中实现，就像我对存储库模式所做的那样）。目前，所有实例化的存储库都有自己的 DbContext / session，并且它的生命周期设置为存储库的生命周期 - 这可能很糟糕 - 我的问题是我不确定是否可以实现一个可以使用的工作单元模式不同的ORM（更确切地说，它可能是，我只是跟不上速度）。

这是唯一想到的：

在我的数据程序集中创建具有函数的 IUnitOfWork: object GetCurrentSession();，然后在 ORM 程序集中的存储库的构造函数中有一个参数，并将其转换为适当的会话/DbContext（如果 NHibernate 然后是 ISession，如果是实体框架然后是 DbContext）

如果有人对这种情况有所了解，我将不胜感激。

假设我有一张桌子people (id, firstname, lastname)。

还有另外两个表应该包含这些字段，所以我们将只重用 people 表：users (id, username, person_id)和companies (id, name, contact_person_id).

现在要获得公司或用户，我们必须加入人员表。如果我们更改 people 表，我们必须重写所有查询，可能还有很多代码。

这是一个真正的问题吗？我的数据库结构有缺陷吗？有没有保持低耦合的解决方案，比如 ORM？

谢谢大家的回答。