标签: decoupling

我当前的应用程序结构是：

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

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

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

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

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

这是我唯一想到的事情：

在我的数据程序集中创建具有以下功能的 IUnitOfWork：object GetCurrentSession();，然后在 ORM 程序集中的存储库的构造函数中添加一个参数，并将其转换为适当的会话/DbContext（如果是 NHibernate，则为 ISession，如果是 Entity Framework，则为 DbContext）

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

我试图将策略模式应用于特定情况,但是我遇到了如何避免将每个具体策略与为其提供数据的上下文对象耦合的问题.以下是以几种不同方式发生的模式的简化情况,但应以类似的方式处理.

我们有一个对象Acquisition提供与特定时间相关的数据 - 基本上是使用不同硬件收集的一堆外部数据.它已经太大了,因为它包含了大量的数据,所以我不想给它任何进一步的责任.我们现在需要采取一些这样的数据,并根据一些配置向一块硬件发送相应的电压.

所以,想象下面的(简化的)类:

class Acquisition
{
    public Int32 IntegrationTime { get; set; }
    public Double Battery { get; set; }
    public Double Signal { get; set; }
}

interface IAnalogOutputter
{
    double getVoltage(Acquisition acq);
}

class BatteryAnalogOutputter : IAnalogOutputter
{
    double getVoltage(Acquisition acq)
    {
        return acq.Battery;
    }
}

现在,每个具体的策略类都必须耦合到我的Acquisition类,它也是最可能被修改的类之一,因为它是我们应用程序的核心.这仍然是对旧设计的改进,旧设计是课堂内的一个巨大的开关声明Acquisition.每种类型的数据都可能有不同的转换方法(虽然电池是一个简单的传递,其他类型根本不是那么简单),所以我觉得战略模式或类似应该是要走的路.

我还要注意,在最终实现中,IAnalogOutputter将是一个抽象类而不是接口.这些类将位于可由用户配置并序列化为XML文件的列表中.该列表必须在运行时可编辑并记住,因此Serializable必须是我们最终解决方案的一部分.如果它有所作为.

如何确保每个实现类获取它需要工作的数据,而不将其绑定到我最重要的类之一？还是我以完全错误的方式处理这类问题？

为了在c#中创建干净的解耦代码,我希望得到一些关于使用动态参数来构造对象的反馈.通常我相信你会创建一个接口并使用接口作为合同,但是你必须为你所有的类创建接口,我觉得它们有点蹩脚......

所以,我的问题是做这样的事情的利弊是什么:

class Class1
{
    public string Description { get; set; }
    public string Name { get; set; }

    public Class1(dynamic obj)
    {
        Name = obj.Name;
        Description = obj.Description;
    }
}

VS

class Class1
{
    public string Description { get; set; }
    public string Name { get; set; }

    public Class1(IClass1 obj)
    {
        Name = obj.Name;
        Description = obj.Description;
    }
}

我正在使用Microsoft XNA框架开发一个游戏项目,尽管这个问题是涉及类/系统解耦的通用问题.

假设我有一个类(简化为适合此示例),如下所示:

public class GameCell
{   
        public Color Color { get; set; }
}

我想在多个使用C#的平台之间重用尽可能多的代码.

直接引用Color结构的问题是这种类型是在XNA程序集中定义的,在我的代码和XNA之间创建了强耦合(或依赖).

我将使用的另一个框架可能(或可能不)具有自己的Color对象,具有自己的一组属性和API.

我希望有相同的源文件"知道"自动使用XNA或其他框架的实现.

我知道其他类型的解耦方法,如IoC,但这意味着我将插入不同版本的系统/类,而不是在不同的上下文中重用相同的类.

这甚至可能吗？您如何建议保持这样的系统便携？

我已经看到了一些情况(在本机C++开发中),你将定义一组类,这些类镜像你正在使用的框架所具有的类(例如这里 - 再次定义Color),因此可以"重新定义映射"稍后根据需要使用不同的类.

另一种选择是使用#IFDEF来处理类的头部中的using语句(从XNA切换到其他平台).在这种情况下,最好的选择是什么？

关于使用实体框架作为数据访问层在MVC3 Web应用程序中解耦我的域层和数据层,我有几个问题.

现在我的控制器完全依赖于EF类,在花了大部分时间阅读依赖注入后,我试图将它们分离.

我的第一个问题是 - 我是否需要将所有EF类有效地复制到我的业务层中？我显然不能再使用EF类了,所以在我看来,我需要创建一个正在使用的每个表类的副本来使其工作.这是正确的吗？例如,如果我的DB中有50个表示50个表的EF类,我是否需要在业务层中创建50个新类？ - >然后无限期地维护它们？这听起来像是很多工作.

其次,我是否正确假设依赖性被翻转而不是业务层依赖于数据层,数据层最终变得依赖于业务层？

我正在开发一个系统,我希望尽可能地将我的图层分离,你知道,某种模块化的应用程序可以在不对系统其他部分进行严格修改的情况下切换数据库和内容.

所以,我一直在关注x-Robert C. Martin关于良好实践,清洁代码,解耦架构等的谈话,以获得一些灵感.我觉得有点奇怪的是他对系统的描述Fitnesse以及他们为WikiPages 实现存储/加载方法的方式.我也在关联视频:Robert C. Martin - 清洁建筑与设计

他描述的内容(至少从我的理解中)是实体知道如何从某个持久层存储和加载自身的机制.当他想将WikiPages存储在内存中时,他只是覆盖了WikiPage并创建了一个新的InMemoryWikiPage.当他想将它们存储在数据库中时,他做了同样的事情......

所以,我的一个问题是 - 这种方法叫做什么？我一直在学习关于存储库模式和内容的所有时间,为什么应该像这样的持久性无知的类,但我似乎无法在他做的这件事上找到任何材料.因为我的应用程序将由模块组成,我认为这可能有助于解决我的问题而无需为我的实体创建一些集中存储......每个模块都会自行处理,包括其实体的持久性.

我认为代码看起来像是这样的:

public class Person : IEntity
{
   public int ID { get;set; }
   public string Name { get;set; }

   public void Save()
   {
       ..
   }

   public void Update()
   {
   }

   public void Delete()
   {
   }

   ...
}

看起来有点奇怪,但......或许我误解了他在视频中所说的话？

我的第二个问题是,如果你不同意这种方法,你会在这种模块化应用程序中采取什么样的路径？

如果可能,请提供一些示例并提供一些解释.

现在我正在开发相当庞大而复杂的webapp并且必须处理大量的客户端js代码,并且为了让我的生活更轻松,我正试图尽可能地解耦这些代码.

我受到Nicholas Zakas(http://www.youtube.com/watch?v=vXjVFPosQHw)和Addy Osmani(http://addyosmani.com/largescalejavascript)谈论可扩展的js架构的巨大启发,并试图应用一些他们的想法对我的工作.

我已将所有代码分隔到多个独立模块中,并使用某种介体处理所有相互通信.在大多数情况下,这种方法很有效.但在某些情况下我认为还不够.

我正在研究的其中一个模块代表了一个非常复杂的类似列表的结构.这是一些简化的例子:

除了一些渲染逻辑,负责这个页面的模块应该处理:

• 分页
• 切换组
• 用dnd移动元素和群体
• 切割/复制/粘贴元素和组
• 刷新证书组/ elems
• elems中的一些逻辑
• 在最近的将来可能会有更多的东西

我已经执行了所有不相关的逻辑(例如编辑和删除逻辑通过事件执行到另一个模块),但模块大小仍然很大(超过1K行代码),我不知道如何减少它.此外,我正在为我的模块使用模块模式,因此在多个文件之间分离逻辑更加困难.

所以我来到这里问有没有办法在单个模块中解耦复杂的逻辑？

更新:

我想澄清一些事情.我非常清楚如何在代码中的多个文件中分离模块("模块"与模块模式) .

但我真正寻找的是在单个模块中分离问题的新逻辑方式(来自NKZ演示的"模块").

我使用依赖注入已经有一段时间了，现在我想向一群新开发人员介绍IoC和DI。我记得自己跟一个人解释过，他问我：

“为什么不仅仅使用：

private IMyInterface _instance = new MyImplementaion();

而不是经历所有DI麻烦。”

我的回答是：“单元测试需要模拟和存根。” -但是我们没有在我的公司中编写单元测试，因此没有说服他。我告诉他，具体实现是不好的，因为您与一个实现紧密相关。更改一个组件将导致另一个组件的更改。

你能举一个这样的代码的例子吗？您能给我更多原因说明此代码不好的原因吗？

对我来说似乎很明显，我很难解释：-)

从我对 OO 设计/模式/原则的所有阅读和研究中，我发现普遍的共识是松耦合（和高内聚）几乎总是更好的设计。我完全同意从我过去的软件项目经验中发言。

但是，假设某个特定的软件公司（我不在其中工作）有一些设计有问题的大型软件，可以与某些硬件进行交互。这些模块（我从未研究过）是如此紧密耦合，并且函数调用可以深入 20 多个级别来管理状态。类边界从来没有明确定义，用例也没有考虑清楚。一个优秀的软件开发人员（不是我）会提出这些问题，但只会被更高级的开发人员拒绝，因为开发实践（如 SOLID 或 TDD）并不真正适用，因为该软件已经使用“传统”方法运行多年，再改变也晚了。客户（我不知道他们是谁）最大的抱怨是产品质量。

由于上述不切实际的场景（我从来没有分开过），我想过是否存在首选甚至需要紧耦合的情况？什么情况下开发人员需要跨越模块边界并共享状态并增加依赖性并降低可测试性？有哪些系统如此复杂以至于需要这样做？我自己想不出一个好的案例，所以我希望一些更有经验的工匠可以帮助我。

谢谢。再说一遍，我不知道这家公司。

我因此而苦苦挣扎:

我的类有一些具有时间耦合的方法.这是,一些方法治法,必须先调用为"初始化"的数据的methodB需要正常工作.

我通常通过将违规依赖项 作为参数传递给"MethodB"来显式化时间耦合,就像在这个片段中一样:

private class SomeClass
{
    private string field;
    private int count;

    public SomeClass()
    {
        MethodA();
        MethodB(field);
    }

    private void MethodA()
    {
        field = "Something";
    }

    private void MethodB(string str)
    {
        count = str.Length;
    }
}

虽然它使事情明确,但我觉得我做错了.我最终得到了根本不使用字段的方法(静态方法!),所以这个类开始变得不那么紧密了.

这是最好的方法吗？(通过传递参数失去凝聚力)

编辑:关于一些建议使用字段作为构造函数中的参数或使用构建器模式来避免无效状态的答案:我不能这样做,因为在我的情况下我正在构建一个Parser.MethodA读取输入并根据它设置状态(从文件中读取字符),然后调用MethodB.必须以正确的顺序调用它们.这是真正的问题:应该在另一个之前调用一个.