问题标签 [coupling]

我在 C# 和 Razor 中有一个 ASP.NET MVC3。应用程序的架构分为数据访问层（EF 类 + 存储库）、服务层、控制器、ViewModels 和 View。

我有两个 EF 类Products（key ProdId）和ProductCategories（key ProductCategoryId）。

他们通过一对多的关系在ProdCatId类Products中作为外键和ProductCategoryId在类中关联ProductCategories。

当然还有一个从类到的导航属性 。hasCategoryProductsProductCategories

我的存储库类中有该方法：

现在我想在我的视图中显示所有带有ProductCategoryName（不是ProdCatId）对应类别的产品。要在我使用的存储库中访问此信息（productDB 是 EF 类）：

为了在我的视图上获得这些信息，我应该使用我的服务层中的这段代码，或者更糟糕的是我的ViewModel中的代码。但是，通过这种方式，我会在想要保持分离的组件（服务层和 EF 或 ViewModel 和 EF）之间创建耦合。

如果我将这个值从我的存储库（方法string GetProductCategory(int ProdId)）获取到我的服务层，连同GetAllProducts().ToList()，我将有两个对象：

1) 一个List<Products>

2) 一个string

如何将这些值传递给我的控制器，然后包装在 ViewModel 中？我应该ProductInfo在包装这些数据的服务层中创建一个类吗？此解决方案创建了Controller、ViewModel和类ProductInfo之间的耦合。

不创建耦合的正确做法是什么？

我在 C# 和 Razor 中有一个 ASP.NET MVC3。应用程序的架构分为数据访问层（EF 类 + 存储库）、服务层、控制器、ViewModels 和 View。

我的ViewModel公开了一个方法，该方法Fill接受要在View中显示的数据集合作为参数。为了在组件之间不存在耦合，必须从服务层或控制器Fill调用该方法？

我在 C# 和 Razor 中有一个 ASP.NET MVC3。应用程序的架构分为数据访问层（EF 类 + 存储库）、服务层、控制器、ViewModels 和 View。

从我的服务层ProductServices，我调用GetAllProducts我的 Repository 公开的方法ProductRepository，它具有以下签名：

因此，在ProductServices我调用 (productRepository是ProductRepository) 的一个实例：

填充变量products。现在我想从 访问产品ProductName名称productServices。如果我使用这个指令：

我正在创建ServiceLayer和EF之间的耦合（绕过存储库）。这意味着我必须添加到ProductRepository带有签名的方法：

但是，由于我的应用程序中需要其他产品信息，我应该为类productRepository的每个字段创建一个方法Product吗？我的推理正确吗？谢谢

我刚刚读了一篇文章，上面写着：

子类耦合。当一个基类型（通常是类）有许多扩展它的派生类型时，理想情况下，其他类型应该只知道基类型。如果所有子类型共享相同的公共接口（从基类型继承的公共成员，为每个子类中的不同行为覆盖），那么外部“客户”类型可以将它们全部视为基类，就好像它们是基类一样。如果不是这样，如果客户端类型知道存在的子类型的细节，那么这就是子类耦合到所讨论的多态结构。

具体来说，最后一行说“如果客户端类型知道有关存在的子类型的详细信息......”。在 .NET 中，如果我使用WebRequest.Create("ftp://...");则我知道FtpWebRequest将返回 an，并且我可以更改特定于FtpWebRequest子类的属性，例如UseBinary属性。除非我对 WebRequest 的子类型有特定的了解，否则我将无法做到这一点，所以在我看来，这是一个子类耦合的情况，并且是糟糕的设计。

我很难相信这是代表 .NET 框架开发人员的糟糕设计，而是想象我对上述内容的理解有点偏离。有人能解释为什么我在 .NET 中提供的示例不是子类耦合的示例吗？

有没有办法以一种可以发送和接收自定义事件的方式将 ManagedBeans 彼此分离——可能是通过（很酷的）FacesContext？！我不想将 Beans 作为 ManagedProperty 注入，以减少直接依赖关系。不幸的是，@ListenerFor 和所有这些新东西只适用于组件和渲染器，而且似乎完全是错误的方法。

熟悉 Adob​​e Flex 事件机制的人都知道我的意思以及我对标准化 Web UI 框架的期望。

请让我知道一种包含在 JSF 规范中的优雅方式，而无需实现另一个框架。

我在处理服务层上完成的“业务验证”时有一个问题。下面的代码显示了一个典型的账户资金转账示例，验证资金充足，转账金额小于定义的限制。

在此示例中，调用者必须处理和捕获 Action 类中定义的异常，并使用相应的 ActionError 来显示错误消息。

对所有业务验证使用异常是“必须”的吗？

如果我决定不为此使用异常，我将不得不在业务层中定义相应的 ActionError（这违反了耦合/内聚）规则在某种意义上。

应该如何处理由服务层传播回 Action 类的消息？

刚从大学毕业，遇到了一些我需要减少耦合的代码。但我并不完全理解所有的概念，并且想要一个简单的例子来帮助我。为了让你开始，我有一个带有单个字段的人员类，名称。我在该类中有一个方法来连接一些文本。

我知道这是一个愚蠢的例子，大多数人永远不会考虑在如此简单的情况下减少耦合，但我只想要一个简单的例子来帮助我完全理解代码和概念。

在主窗口后面的代码中，我放置了一个文本框和一个按钮。当窗口加载时，它会显示人员 x 姓名字段的当前值。单击按钮时，将调用 x.PersonAddText 方法。目前，此示例的耦合计算为 8。按钮单击事件为 3，窗口加载事件为 3。

有什么办法吗，使用这个例子，我们可以将它们中的一个或两个都降低到低于这个值。

以下是我的所有代码：

我的个人类：

我的代码背后：

我的简单 XAML：

我很难理解互联网上解释这一点的教程。据我所知，有 3 种方法可以做到这一点（如果可能的话，将上面的代码转换为所有这三种方法的示例会很好）：

• 服务定位器
• 依赖注入
• 控制反转 (IoC)

解释我读过的东西的文章非常好，但这些例子与我无关，因为他正在使用带有数据库连接字符串的 VB 和 ASP.Net。这与我所需要的完全相反，我不想在学习概念的同时考虑如何翻译代码，也不想考虑如何将其应用到相关的东西上。虽然这个例子很好，但它太多了，我真的很感激任何额外的帮助。

编辑历史：更正拼写。添加以下内容以澄清我的问题：

我理解耦合和内聚背后的理论，以及为什么你应该减少一个并增加另一个。但是我们在大学里从来没有编写过任何例子。另外，虽然在大学里没有涉及，但我确实了解接口。但是，我不明白如何使用它们来减少耦合。

添加了我上面引用的文章的链接。

编辑2：到目前为止，我现在得到的是以下内容：

我现在如何在后面的主窗口代码中使用它？我想我应该更换

和

这是正确的吗？如果是，我还需要做什么。我问的原因是因为我仍然没有看到 Visual Studio 报告的代码耦合数字有任何减少（事实上，它在后面的主窗口代码上增加了 1）。

我的问题是：哪种模式的耦合度较低？在现实世界中哪种模式更受欢迎？

我是 R 的工程师新手，并且有一个必须在 linux 上运行的脚本，我进行了很多搜索，但找不到在 linux 上运行脚本的简单命令。我必须将我的工程软件与 R 结合起来，所以我也需要在 linux 上运行它。

请帮助我启动。

最好的祝福。

承担方法M1并M2 具有密切相关的职责

第一个例子：

如果

•M1和M2在类中定义A（因此类A是高度内聚的）

• 类B用途A.M1和类C用途A.M2

然后

•A与B和C类耦合

• 更改 will 的签名 M1只需要更改 in B，而不需要更改C

第二个例子：

如果

•M1在类中定义A1（因此B与 耦合A1）

•与M2类一起定义A2（因此C与 耦合A2）

然后

• 更改 will 的签名M1只需要更改 in B，而不需要更改C

a）据我了解，上一个示例中的类并不比第一个示例中的类更耦合！还是我错过了什么？

b）据我所知，第一个示例中的类比第二个示例中的类更松散耦合，前提是：

• 我们假设更改 的签名M1也需要我们更改 的签名M2，但我不认为这种情况经常发生？！

• 或者如果两者都M1对M2相同类型的数据 T1 进行操作，那么将 T1 替换为 T2 将需要同时更改M1和M2？！

• 或者，如果我们假设由于M1并且具有密切相关的责任，那么改变通常需要M2改变的机会要大得多（即使不直接或间接调用）？！M1M2M1M2

• 或者，如果我们假设由于M1并且具有密切相关的职责，那么某些类需要两者的M2可能性要大得多（因此在单个类中具有and会减少耦合）？！M1M2M1M2

M1c) 定义and M2within A（而不是定义M1withinA1和M2within ）是否有任何其他原因A2会减少耦合？

注意 - 我知道我们应该拥有高度内聚的模块，因为它更易于维护和可重用

谢谢