相关疑难解决方法(0)

我正在寻找一个非常简单和轻量级的IoC容器,其C#源代码可以包含在我自己的项目中(因此不会进行外部引用).

这样做的原因是我正在编写基础结构,并希望提供单个.dll文件,而不需要任何其他依赖项.

我也不想用IoC组件ILMerge我的组件..

我想过MEF,其他一些建议？

有时我的课程需要获取一些构建信息。我不是在谈论对其他对象（将被注入）的引用，而是在谈论（例如）包含唯一信息的字符串：

// Scoped as singleton!
class Repository
{
    public Repository( InjectedObject injectedObject, string path ) { ... }
}

你如何注入这个字符串？一种可能性是编写一个Init()方法并避免注入字符串：

class Repository
{
    public Repository( InjectedObject injectedObject ) { ... }
    public void Init( string path ) { ... }
}

另一种可能性是将信息包装到一个可以注入的对象中：

class InjectedRepositoryPath
{
    public InjectedRepositoryPath( string path ) { ... }
    public string Path { get; private set; }
}

class Repository
{
    public Repository( InjectedObject injectedObject, InjectedRepositoryPath path ) { ... }
}

这样我就必须InjectedRepositoryPath …

我正在开发一种软​​件产品,可以根据提供的配置和元数据显着改变行为.

我想知道构建/构建高度可配置的软件产品的最佳实践.考虑到有大量的配置参数,我想在看一下依赖注入之前先看一下不会影响性能的东西.我的平台是.Net ......我寻求有关架构/设计和实现前端的建议.

TDD现在风靡一时,越来越多的软件商店正在转向敏捷,scrum等.我当然可以看到自动化测试的优势,但我也看到TDD与良好的面向对象设计的某些原则相矛盾.

TDD要求您在代码中插入接缝,通过接口公开实现细节.依赖注入或协作者注入违反了信息隐藏原则.如果您的类使用协作者类,那么这些协作者的构造应该是类的内部,而不是通过构造函数或接口公开.

我没有看到任何文献解决编写可测试代码之间的冲突,同时坚持封装,简单和信息隐藏的原则.是否以任何标准方式解决了这些问题？

我想知道实例化温莎城堡容器的最佳位置在一个类库中.

我应该只在我正在使用的类的构造函数中执行它,还是有一个我不知道的程序集入口点？

谢谢.

我正在尝试上班的应用程序使用MVVM.这篇文章的最大部分是对我尝试过的内容和我工作的内容的解释.问题接近帖子的底部.使用的Localizer类仅在此处用作示例,并且可以很容易地用另一个类替换.

我有class library一个Localizer班级.此类的目的是即时更改应用程序的语言,而无需重新启动应用程序.`Localizer必须先实例化才能使用,但一旦实例化,就应该可以在整个应用程序中使用.(该类使用应用程序资源来本地化应用程序.)

我的第一个方法我能想到的是制作的Localizer一个public static class带一个public static void Initialize方法.这样我可以初始化Localizer这样的

Localizer.Initialize(/* Needed arguments here */);

在应用程序级别,并在我的类库或这样的应用程序中的任何地方使用它

string example = Localizer.GetString(/* A key in the resource dictionary */);

考虑到类库是由我编写的(只有我有源代码)并且被其他人使用,他们对源代码一无所知(他们只知道类库可以做什么),我必须在某种情况下明确说明他们需要Localizer.Initialize在应用程序级别调用"如何使用此类库",以便在应用程序的任何位置使用它.

经过一些研究后,很多人都说这是一个不好的做法,并建议研究什么是依赖注入(DI)和控制反转(IoC),所以我做了.我了解到DI与我的第一种方法大致相同,但删除静态内容,Localizer.Initialize用作构造函数并在其他类中注入实例化类.

所以第二种方法是依赖注入,这就是我被困住的地方.我设法让我的应用程序使用单个代码进行编译,MainWindowView并MainWindowViewModel使用以下代码:

protected override void OnStartup(StartupEventArgs e)
{
    ILocalizer localizer = new Localizer(Current.Resources, System.Reflection.Assembly.GetExecutingAssembly().GetName().Name, "Languages", "Language", "en");

    var mainWindowViewModel = new MainWindowViewModel(localizer); …

我认为接口,多态性和通过依赖注入的控制反转等模式的全部原因是为了避免紧耦合,分离,模块化等等.

那么为什么我必须明确地将接口"连接"到ASP.NET中的具体类？会不会有我的注册表是某些类型的耦合？喜欢,

services.AddTransient<ILogger, DatabaseLogger>();

如果我使用记录器,ILogger并创建实现该接口的文件和数据库类,该怎么办？

在我的IoC中,

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp1
{
    public interface ILogger
    {
        void logThis(string message);

    }
    public class DatabaseLogger : ILogger
    {
        public void logThis(string message)
        {
            //INSERT INTO table.....
            System.Console.WriteLine("inserted into a databse table");
        }

    }
    public class FileLogger : ILogger
    {
        public void logThis(string message)
        {
            System.Console.WriteLine("logged via file");
        }

    }
    public class DemoClass
    {
        public ILogger myLogger;


        public DemoClass(ILogger myLogger)
        {
            this.myLogger = myLogger; …

我有一个工厂类,它决定它应该实例化和返回的四个可用子类中的哪一个.正如您所料,所有子类都实现相同的接口:

public static class FooFactory{
     public IFoo CreateFoo(FooEnum enum){
            switch (enum)
            {
                case Foo1:
                    return new Foo1();
                case Foo2:
                    return new Foo2();
                 case Foo3:
                    return new Foo3(IBar);//has a constructor dependency on IBar
                case Foo4:
                    return new Foo4();
                 default:
                    throw new Exception("invalid foo!");
            }
     }
}

如您所见,其中一个子类在其构造函数中定义了依赖项.

一些兴趣点:

• 我们使用Spring.NET作为IoC.
• 所有子类IFoo都是域对象,因此不会被Spring.NET实例化.如果可能的话,我想保持这种方式.
• 该应用程序有一个手写的数据访问层(呕吐),因此这里没有ORM.

我试图找出如何最好地将IBar依赖关系传递Foo3给FooFactory.我觉得这可能是通过IoC最好解决的问题,但我不能理解如何.我还希望尽可能保持FooFactory单元可测试:即我不希望在测试代码中依赖Spring.NET.

谢谢阅读.

我一直在这里开发一个新的MVVM框架.

它有一些有趣的概念,但我想支持多个IoC容器.现在我只支持MEF,因为它带有.Net 4.0.

我应该从一开始就考虑哪些更常见的IoC/DI框架？我想也许3个左右.

温莎城堡？Ninject？

编辑:

为了澄清,我问的是今天常用的IoC/DI框架.我希望也能学到一些新的热点,我还没有听说过.

有人说使用依赖注入更好.这是为什么？

我认为最好是拥有一些全局的,易于访问的类,而不是庞大的构造函数.

它会以任何方式影响应用程序的速度吗？

这两者的混合可能是最好的.

很长一段时间以来,我们很幸运有了公共服务定位器(CSL)来解决来自未知来源的服务.但是,从来没有任何与容器无关的解决方案首先注册这些服务.我们一直面临着必须将组合代码耦合到特定IoC容器的问题,此外,还致力于在整个应用程序中使用该容器.

我觉得我可能试图在这里实现不可能,但是有没有人对如何实现公共服务注册表(CSR)有任何想法？

我最初的想法是使用MEF来解析各种IContainerIntegrators(每个容器技术一个类),然后使用MEF来解析各种IXXXContainerBindings(每种技术的一个接口).然后,用户可以围绕容器绑定开发应用程序,只需将其绑定放入BIN目录即可实现插件体系结构.如果他们想要使用新的容器技术,那么他们只需要开发一个新的IContainerIntegrator类和附带的IXXXContainerBinding,然后他们将用它们来编写自己的绑定.在应用程序启动时,CSR使用ServiceLocatorAggregator类将所有容器实例聚合到单个CSL中.

我有这个工作,但面临以下问题:

• 任何调用当前(不完整)容器的绑定都是不稳定的,因为之前的注册可能会被后续绑定覆盖.这包括需要解析对象以进行注册决策的绑定(即"如果存在则绑定它").
• 可能存在两个绑定,它们暴露同一组服务.但是,我们希望"交织"这些注册.例如'我希望服务A和C来自绑定X,服务B和D来自绑定Y'.
• 当自动连接所请求服务的依赖关系时,容器会自行解析服务.例如'container.Bind <This> .To <That>()'将自动注入来自'container'解析的服务的实现 - 而不是来自聚合服务定位器.

如果我完全忽略了这一点,请大声喊叫,但这不是依赖管理最脱钩的解决方案吗？不是很好吗？我即将开始使用插件架构开展大型企业项目.我不想承诺特定的IoC容器.

(ps这个问题是关于容器不可知的组合,它支持发现.请不要进入关于SL与DI的争论.在组合中使用SL,这就是我在这里引用它的原因).

我们还需要几个月的时间才能重新设计产品的逻辑和业务层.通过利用MEF(依赖注入),我们已经实现了高水平的代码覆盖率,我相信我们拥有非常可靠的产品.由于我们一直在研究一些更复杂的逻辑,我发现单元测试越来越困难.

我们正在利用CompositionContainer来查询这些复杂算法所需的类型.我的单元测试有时难以遵循,因为必须进行冗长的模拟对象设置过程,恰到好处,以允许验证某些情况.我的单元测试通常比我试图测试的代码花费更长的时间来编写.

我意识到这不仅是依赖注入的问题,而且是整个设计的问题.对于我过于复杂的测试,是不是很差的方法设计或缺乏组合？我已经尝试过基类分析测试,创建常用的模拟对象并确保尽可能地利用容器来缓解这个问题,但我的测试总是非常复杂且难以调试.您已经看到哪些提示可以使这些测试简洁,可读且有效？

我想知道在c#(或者甚至是cli)中是否有一种标准方法可以有效地将实现逻辑分离为单独的类库/程序集,这些库/程序集将由一个进程动态加载,该进程将基于公共接口对这些库执行操作.

更确切地说:假设我正在构建一个接收消息的服务,并将这些消息的处理委托给其他人.就像是:

while(true){
   message = read_message_from_somewhere();
   class_from_another_lib.do_somthing_with_Message(message); 
}

我希望进程从某种配置中在运行时加载类lib.我假设lib会有一些主类或类工厂实现一些接口部分,如下所示:

ISomePublicIface{
   void do_somthing_with_Message(messageT);
}

这一切都感觉有些java isish我需要做的就是在一个程序集中使用一个类可注入的接口在应用程序配置中添加一行并免费获得一些东西.