问题标签 [coupling]

背景

我的解决方案包括两个项目：

1. 标准的 Windows 应用程序
2. 我的应用程序不直接使用的 DLL ，而是将其注入目标进程

基本上，从我的应用程序的角度来看，DLL 必须满足的唯一要求是存在于我的应用程序的工作目录中。简而言之，我的 DLL 不会导出我的应用程序感兴趣的任何函数。

问题

我想强烈耦合这两个二进制文件。除了在我的应用程序中手动调用之外，我还有哪些选择LoadLibrary？

如果这太模糊，请告诉我。

编辑

由于似乎没有人“回答”，我最终做了EFraim建议（见评论）。

我从我的 DLL 中导出了一个虚拟函数，并将 DLL 生成的*.lib文件作为附加依赖项添加到我的应用程序的链接器属性表中。现在，在运行时，如果缺少 DLL，Windows 会给出一个很好的错误消息并终止执行。额外的好处是，在 IAT 初始化成功后，DLL 映像也会被锁定；这可以防止用户删除之类的事情。

我最近刚刚学习了PureMVC框架，对 Proxy 和 Mediator 对象之间的耦合有点困惑。此页面上的链接连接到描述该框架的一些文档。（请注意，上述页面上的链接会打开 PDF。）

我研究过的 PureMVC 图表和示例经常显示 Mediator 和 Proxy 之间的直接耦合。当代理的状态更新时，而不是发送一个新的通知，中介者（它从门面检索对代理的引用）更新其状态。

这当然似乎简化了代码的逻辑，但它也直接将两个看似完全不同的组件耦合在一起。据我了解，Mediator 的目的是将事件从视图转换为 PureMVC 通知。代理旨在执行一些功能来收集数据并将其转发回视图。这两个组件似乎存在于应用程序的不同层中，也许不一定要耦合在一起。

让 Proxy 对象在状态更新时发送自己的通知不是更有意义，这些通知由 Facade 转发给感兴趣的 Mediator 吗？

如果这是一个骗局，请原谅我，但我找不到任何符合这个确切问题的东西。

我正在使用一个耦合非常紧密的遗留应用程序。我们正在提取一些主要功能，因为我们将从外部服务中获取该功能。

开始删除现在未使用的代码的最佳方法是什么？我应该从极端基础开始，移除并重构我的堆栈吗？午餐期间，我将去看一看《有效地使用旧代码》。

我刚看完 NDC 的 Bob Martin 的一集，他说页面顶部的 C# 中的“使用”指令很糟糕，因为它们在组件之间创建/暗示了紧密耦合。

有什么方法可以在不添加项目引用和 using 语句的情况下使用外部 .dll？

我记得 V6 曾经让您通过 ProgId 的字符串创建一个对象——我不确定这是我正在寻找的技术，但它是一个不需要项目引用即可使用的语言示例dll。

编辑：这是会议的链接。抱歉，演讲中没有确切的报价或分钟，我是凭记忆进行的。

我的项目中有两个类（使用 ASP.NET MVC）：AuthenticationService 和 ProfileService。当新用户在我的站点注册时，Authentication 控制器的 Register 操作调用 IAuthenticationService 中的 Register 方法，该方法根据接口所指的任何具体身份验证模块为用户创建身份验证记录（注入到控制器的构造函数中）。作为注册过程的一部分，将为用户创建配置文件记录，该配置文件记录是通过在注入的 IProfileService 上调用 CreateProfile(User) 来创建的。

目前控制器正在调用这两个服务，但我喜欢我的控制器执行尽可能少的业务逻辑的想法。我想知道除了让身份验证服务知道配置文件服务之外是否还有其他选择，这反过来又需要 IAuthenticationService 的任何未来实现知道调用 CreateProfile？我不禁觉得上面写满了代码气味。

另一种可能性是让第三个服务 {I,}RegistrationService 负责逻辑。

处理这种情况的推荐或首选方法是什么？谢谢

类名已更改以保护无辜者。

如果我有一个名为 ISomeInterface 的接口。我也有继承接口的类，FirstClass 和 SecondClass。FirstClass 使用必须释放的资源。二等舱没有。

所以问题是，我应该从哪里继承 IDisposable？以下两个选项似乎都不理想：

1）使 FirstClass 继承 IDisposable。然后，任何处理 ISomeInterfaces 的代码都必须知道是否要处理它们。这对我来说就像紧耦合。

2）使 ISomeInterface 继承 IDisposable。然后，任何从它继承的类都必须实现 IDisposable，即使没有要处置的东西。Dispose 方法基本上是空白的，除了注释。

#2 对我来说似乎是正确的选择，但我想知道是否有其他选择。

编写一个定义依赖于另一个库的接口的库是不好的做法吗？

我知道紧耦合不好，但是在使用 .NET 类时这仍然适用吗？

例如，在 .NET 中，如果我有一个返回 Color 对象的库，它将强制依赖 System.Drawing 对使用我的库的任何内容。在我的库中创建自己的 Color-type 类会更好吗？

一个模型可以依赖另一个模型吗？假设我有一个其他模型想要访问的日志模型。

假设我有许多用户控件，每个用户控件在一个 tabitem 内，在一个窗口内。

例如，假设这是一个食物收集应用程序。然后我们有标签水果、蔬菜和零食。每个选项卡将显示该主题的食物列表，并允许用户添加、删除、修改每个部分中的食物。食物存储在单独的文本文件中，即 Fruit.txt、Vegetable.txt、Snack.txt

实际的文本文件可能看起来像这样（vegetable.txt）：

现在这是一个大列表，并且有一个加载方法可以将所有蔬菜拉到一个列表中

我的问题是这个 loadVegetables 方法在文件后面的代码中，我最终在整个地方重复这个加载方法，因为我有另一个其他屏幕，如 ReviewAllFood、AddVegetable 等以及所有其他加载方法水果和零食。

这更像是一个设计问题，我想知道如何设置它以不重复此代码。我可以在 load 方法所在的位置有一个 VegetableManager（或其他东西）类，但这实际上意味着更少的重复代码吗？然后在每个屏幕中，我必须创建 VegetarianManager 的对象并调用它的加载方法。所以我想效率方面并没有更好，但我确实实现了更好的设计。

我想我在这里遗漏了一些东西。自从我学习内聚和耦合已经有一段时间了，我想我现在对这些概念感到困惑。欣赏是否有人可以针对这种情况提出设计建议，并解释他们为什么选择它以及为什么它比我目前的做法更好。

谢谢阅读。

在 n 层架构中，放置对象关系映射 (OR/M) 代码的最佳位置是数据访问层。例如，可以将数据库查询和更新委托给 NHibernate 之类的工具。

然而，我想将所有对 NHibernate 的引用保留在数据访问层中，并将依赖关系抽象到远离其下方或上方的层。这样，我可以交换或插入另一个 OR/M 工具（例如实体框架）或某种方法（例如普通的存储过程调用、模拟对象），而不会导致编译时错误或对整个应用程序进行大修。可测试性是一个额外的好处。

有人可以建议一个包装器（即接口或基类）或方法来保持 OR/M 松散耦合并包含在 1 层中吗？或者指向我有帮助的资源？

谢谢。