问题标签 [loose-coupling]

我有InvoiceInputModel一个ProjectId属性，它是对Project实体的引用。理想情况下，我希望 AutoMapper 能够从 映射整个Invoice实体InvoiceInputModel，如下所示：

显然以下是不好的：

如何告诉 AutoMapper在保持松耦合的同时invoice.Project应该根据属性映射到Project实体？ProjectIdInvoiceInputModel

我的发票/编辑InvoiceController：

我发现了一些关于“解析器”和 ResolveUsing 的东西，但我没有使用它的经验。

如何告诉 AutoMapper 这样做，同时保持实体模型、输入模型和视图模型之间的松散耦合？或者，还有更好的方法？

我有一个用 C# 编码的 ASP.NET MVC 应用程序。该应用程序的结构如下：

1. 控制器

2. 存储库

3. LINQ to Entity（实体框架）

4. 看法

我使用 Repository( _ProductRep) 来查询 LINQ to Entities 并将实际实体提供给控制器List<T>，或者不提供IQueriables<T>。

对于我有更多疑问的情况，我想获得一些帮助。我有以下代码：

在我得到这个之后，lproduct_monthlyReport我需要在 foreach 中查询它并获取一个特定的记录。目前我实现了这样的解决方案：

litemList产品可以拥有的所有可能项目的列表在哪里。

我想知道这个解决方案是否明智地增加了耦合（并且违反了Demeter 定律）或者它是可以接受的，因为我实际上是在查询 aList<T>而不是 a IQueriable<T>。如果我错了，请纠正我，但我猜由于 List 不需要访问 EF DataContext，因此 Controller 和 EF 之间没有耦合。

如果我错了，我能想到的唯一解决方案是用 Repository 方法替换查询（我仍然必须实现）：

但是，使用此解决方案，存储库在每个循环周期中使用 4 个条件进行一次查询，而在之前的解决方案中，存储库仅使用一个条件进行查询。

能否请您就这个问题赐教？谢谢。

PS：我需要两个变量lproduct_monthlyReport和lproductItem_monthlyReport循环内部，我不能只使用其中一个

PPS：我知道我应该在 Controller 和 Repository 之间建立一个业务服务层，这是我的下一步。

例如，我有一个模型类来处理从其他 iPhone 接收蓝牙消息。当我收到其中一条消息时，我需要更新视图。我相信这样做的标准方法是通过视图控制器。视图控制器具有对模型和视图的引用，因此可以与它们中的每一个进行通信。

但是他们应该如何将消息发送回 VC？它们每个都可以引用视图控制器（作为属性，分配不保留）。这是不好的做法（如果我没记错它是循环引用）？
有没有其他方法可以做到这一点？我已经考虑过委托模式，但是要编写一个完整的委托，对于一个简单的问题来说似乎需要做很多工作。或者，如果您认为我想太多了，请随时告诉我！

【我觉得这个问题之前大概也出现过，好像挺常见的，但是我搜索了一下，没找到太多】

谢谢你的帮助，

我正在 ASP.NET MVC 中创建一个 REST API。我希望请求和响应的格式是 JSON 或 XML，但是我也想让添加另一种数据格式变得容易，并且容易先创建 XML，然后再添加 JSON。

基本上我想指定我的 API GET/POST/PUT/DELETE 请求的所有内部工作，而不必考虑数据以什么格式进入或它将以什么格式离开，我可以在以后轻松指定格式或更改它每个客户。所以一个人可以使用 JSON，一个人可以使用 XML，一个人可以使用 XHTML。后来我也可以添加另一种格式，而不必重写大量代码。

我不想在所有操作的末尾添加一堆 if/then 语句并确定数据格式，我猜有某种方法可以使用接口或继承等来做到这一点，只是不确定最好的方法。

我得到了这组代码，需要提出改进代码内聚和类耦合的方法。但我认为这些类很好地解耦，因为看起来它们正在使用事件。就凝聚力而言，所有的 init() 调用都放在一起，对我来说一切都很好。

还有办法提高类的内聚和耦合吗？对我来说看起来不错，但我想我错过了一些东西。

感谢您对此提出任何建议。

我有一个关于松散耦合和接口的概念/理论问题。

所以使用接口的一种方法可能是封装某个构造函数所需的参数：

所以只要传入的对象实现了契约，一切都会工作。据我了解，这里的主要好处是它支持多态性，但我不确定这是否真的与松散耦合有关。

让我们说一个 IFooInterface 如下：

从松散耦合的角度来看，不要在上面的构造函数中使用 IFooInterface 会更好，而是像这样设置 Foo ：

因为说我想把 Foo 的功能放到另一个项目中。这意味着其他项目也必须引用 IFooInterface，添加另一个依赖项。但是这样我可以将 Foo 放到另一个项目中，它准确地表达了它需要什么才能工作。显然我可以只使用重载的构造函数，但是为了论证的缘故，我不想和/或不能修改 Foo 的构造函数。

最显着的缺点（至少对我而言）是，如果您有一个带有一堆原始参数的方法，它会变得丑陋且难以阅读。所以我有了创建一种包装函数的想法，它允许您仍然传递接口而不是所有原始类型：

这里的想法是，我可以取回一个函数，该函数采用符合 Foo 要求的某个接口的实例，但 Foo 实际上对该接口一无所知。它可以像这样使用：

我听说过关于接口应该如何启用松散耦合的讨论，但对此感到疑惑。

想知道一些有经验的程序员是怎么想的。

我正在使用 ASP.NET MVC3 和 SQL Server 中的数据库开发一个 Web 应用程序项目。还有一个移动应用程序通过 REST 服务使用来自同一数据库的数据。以下是我的应用程序的一些层：

• 模型- ADO.NET 数据模型，使用实体框架

• 数据访问层- 具有从数据库中检索数据的查询的存储库

• Web 应用程序- MVC3 项目，使用存储库，使用结构映射和 DI 松散耦合，数据库上下文在 HttpRequest 结束时被释放

• 核心- DAL 和服务层之间的另一层，使用存储库并将数据公开给服务层。业务逻辑层的排序。

• 服务层- REST 服务，了解核心层但不了解 DAL。将数据映射到 DTO 并暴露给客户端

我遇到的这种应用程序架构的问题是服务层上的松散耦合。服务层参考核心层。核心层引用了数据访问层并使用其存储库。但是，存储库没有默认构造函数。他们期望 1 个参数及其数据库对象上下文（一次性对象）。

直接在我的网站上使用存储库不是问题。我正在使用结构图，而 DI 使其松散耦合。每个上下文都在 HttpRequest 的末尾进行处理。

问题在于服务层和核心层。我也想在那里有松散耦合，但不知道如何实现它？如何将数据上下文注入其中并确保它在特定时刻得到处理？我想听听一些关于如何将它们组合在一起的建议。

假设我创建了一个应用程序博客 [这无关紧要，它就在那里，所以我可以做 app.blog.posts - 所以它实际上只是一个文件夹] 然后在博客中我在博客中创建应用程序帖子，帖子定义了模型帖子. 完成此操作后，我将在博客中创建一个应用程序类别，该类别应扩展模型帖子（或任何类似帖子的模型——将类别字段添加到帖子），然后创建它自己的表。如果这些应用程序完全不相关（例如：django-tags），类别如何能够在最终不知道的情况下扩展帖子？我对 django 松耦合有点困惑，所以也许有人可以向我解释一下（除非已经有例子，但我找不到遵循这种思维方式的好例子。）

我正在构建一个 Flash 应用程序（只是带有 FlashDevelop 的 AS3），我在保持事件系统周围松散耦合时遇到了一些麻烦。我已经阅读了大量有关中央事件系统和静态事件调度程序的内容，但它们并不完全适合我。

我正在构建的类似于视频播放器。我有一个Player类，它是应用程序所有其他小部分的父类。Player类扩展了Sprite，我目前对其进行了设计，以便您可以实例化多个Player并将它们放在舞台上。我还有一个扩展EventDispatcher的Controller类，我通过这个类调度我的所有事件。这是一个中心事件类。

问题是我需要传递对此类的引用，以便所有其他类都可以通过它进行调度和侦听。 传递参考作品，但它与松散耦合完全相反。我知道我可以制作一个所有班级都可以看到的静态 EventDispatcher，但是如果我在舞台上有两三个 Player，他们都会听到彼此的事件。

如何创建一种沙箱类型，允许Player实例的所有子类在不传递引用或使其静态的情况下了解中央调度程序？

我与我的同事就某些逻辑是否属于数据访问层或业务逻辑层进行了辩论。

场景是，BLL 需要一些数据来处理。该数据主要存在于数据库中。我们希望缓存该数据（使用 System.Runtime.Caching），以便在后续请求中快速可用。该体系结构使得 DAL 和 BLL 存在于同一个盒子和不同的程序集中（同一解决方案中的项目）。所以不用担心通过电线或类似的东西击中 DAL。

我的论点是，命中缓存与数据库的决定是 DAL 关心的问题。业务逻辑层不应该关心数据来自哪里，只关心它获取所需的数据。

他的论点是，数据访问层应该是“纯粹的”和“愚蠢的”，任何决定命中缓存还是数据库的逻辑都应该在业务逻辑层中。

在我看来，当目标是保持松散耦合时，他的意思是破坏关注点分离并导致层更紧密地耦合。如果 BLL 是一个特定的程序/ui 函数来决定去哪里获取数据，我可以看到 BLL 可能想要控制的位置，但这里根本不是这种情况。这只是一个非常简单的缓存场景，其中数据库是主数据存储。

想法？