相关疑难解决方法(0)

我正在思考一个C#库的设计,它将有几个不同的高级函数.当然,这些高级功能将尽可能使用SOLID类设计原则来实现.因此,可能存在供消费者定期直接使用的类,以及作为那些更常见的"最终用户"类的依赖性的"支持类".

问题是,设计库的最佳方法是:

• DI不可知 - 虽然为一个或两个常见的DI库(StructureMap,Ninject等)添加基本的"支持"似乎是合理的,但我希望消费者能够将该库与任何DI框架一起使用.
• 非DI可用 - 如果库的使用者没有使用DI,那么库应该仍然尽可能容易使用,减少了用户为创建所有这些"不重要"的依赖关系而必须完成的工作量.他们想要使用的"真实"类.

我目前的想法是为常见的DI库提供一些"DI注册模块"(例如,一个StructureMap注册表,一个Ninject模块),以及一个非DI的集合或工厂类,并包含与这几个工厂的耦合.

思考？

如何将IoC容器用于单元测试？使用IoC在大型解决方案(50多个项目)中管理模拟是否有用？有经验吗？任何C#库在单元测试中都能很好地使用它吗？

我正在探索依赖注入,并且在整个地方使用术语组合根.那是什么？

我正在使用IoC框架,我选择使用Unity.我还没有完全理解的一件事是如何更深入地解析应用程序中的对象.我怀疑我当时还没有灯泡可以说清楚.

因此,我尝试在psuedo'ish代码中执行以下操作

void Workflow(IUnityContatiner contatiner, XPathNavigator someXml)
{
   testSuiteParser = container.Resolve<ITestSuiteParser>
   TestSuite testSuite = testSuiteParser.Parse(SomeXml) 
   // Do some mind blowing stuff here
}

所以testSuiteParser.Parse执行以下操作

TestSuite Parse(XPathNavigator someXml)
{
    TestStuite testSuite = ??? // I want to get this from my Unity Container
    List<XPathNavigator> aListOfNodes = DoSomeThingToGetNodes(someXml)

    foreach (XPathNavigator blah in aListOfNodes)
    {
        //EDIT I want to get this from my Unity Container
        TestCase testCase = new TestCase() 
        testSuite.TestCase.Add(testCase);
    } 
}

我可以看到三个选项:

1. 创建一个Singleton来存储我可以在任何地方访问的Unity容器.我真的不喜欢这种方法.添加这样的依赖项来使用依赖注入框架似乎有点奇怪.
2. 将IUnityContainer传递给我的TestSuiteParser类及其中的每个子类(假设它是n级深度或实际上大约3级深度).在任何地方传递IUnityContainer只是看起来很奇怪.我可能只需要克服这一点.
3. 在正确的方式上使用Unity的灯泡时刻.希望有人可以帮助轻弹开关.

[编辑]我不清楚的一件事是我想为foreach语句的每次迭代创建一个新的测试用例实例.上面的示例需要解析测试套件配置并填充测试用例对象的集合

我的应用程序中将包含以下组件

• 数据访问
• DataAccess.Test
• 商业
• Business.Test
• 应用

我希望使用Castle Windsor作为IoC来粘合各层,但我对胶合的设计有点不确定.

我的问题是谁应该负责将物品注册到温莎？我有几个想法;

1. 每个层都可以注册自己的对象.为了测试BL,测试平台可以为DAL注册模拟类.
2. 每个层都可以注册其依赖项的对象,例如业务层注册数据访问层的组件.要测试BL,测试平台必须卸载"真正的"DAL对象并注册模拟对象.
3. 应用程序(或测试应用程序)注册依赖项的所有对象.

有人可以用不同的途径帮助我提出一些想法和利弊吗？以这种方式利用Castle Windsor的示例项目的链接将非常有用.

我试图了解何时应该使用容器而不是手动注入依赖项.如果我有一个使用1-2接口的应用程序,并且每个接口只有1-2个具体实现,我会倾向于自己处理.

如果我有一个使用2-3个接口的小应用程序,每个接口有2-3个具体实现,我应该使用一个完整的容器吗？像这样简单的东西就足够了吗？

基本上我试图理解何时适合手动处理这些依赖关系,什么时候(或者如果)我应该使用像上面那样简单的东西,何时使用像Ninject,Windsor等的IOC容器....它可能不会适合在这样的事情上加上一个数字,但我怎么能告诉它是时候使用IOC容器了？

我与refrences如本描述去一个三层应用程序的答案:

DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app

为了让这种依赖注入运行,我看到了几个选项:
1.从web-app添加对DAL的引用,以便能够在应用程序启动时设置绑定.
2.使用具有xml配置的容器
(3.使用反射加载dal-assembly并查找类型)

选项1.很简单,也可以将DAL.dll复制到bin但是我突然重新引入了我努力摆脱的引用.现在可以直接访问存储库.选项2和3似乎不必要地复杂.

没有其他办法吗？

试图找出如何最好地处理以下场景:

假设一个RequestContext依赖于外部服务的类,例如:

public class RequestContext : IRequestContext
{
    private readonly ServiceFactory<IWeatherService> _weatherService;

    public RequestContext(ServiceFactory<IWeatherService> weatherService, UserLocation location, string query)
    {
       _weatherService = weatherService;
       ...

我应该在最终实例化的类中需要什么样的依赖RequestContext？它可能是ServiceFactory<IWeatherService>,但这似乎不对,或者我可以创建一个IRequestContextFactory以下的线:

public class RequestContextFactory : IRequestContextFactory
{
    private readonly ServiceFactory<IWeatherService> _weatherService;

    public RequestContextFactory(ServiceFactory<IWeatherService> weatherService)
    {
        _weatherService = weatherService;
    }

    public RequestContext Create(UserLocation location, string query)
    {
        return new RequestContext(_weatherService, location, query);
    }
}

然后传递IRequestContextFactory构造函数注入.

这似乎是一种很好的方法,但这种方法的问题在于我认为它阻碍了可发现性(开发人员必须了解工厂并实施它,这并不是很明显).

我错过了更好/更可发现的方式吗？

嘿伙计们,我想听听你在控制器级别和/或域级别应用依赖注入的主要优点和缺点是什么.

让我解释; 如果我收到IUserRepository作为我的用户的参数,我可以通过两种方式进行:

1)我直接在我的域对象上注入IUserRepository,然后在没有新对象的情况下在控制器级别使用User,这意味着,我从DI容器中准备好它们.

2)我在我的控制器上注入了IUserRepository(比如Register.aspx.cs),然后我使用来自DI容器的依赖项新建了所有域对象.

昨天,当我和我的朋友交谈时,他告诉我,如果你从容器中获取你的域对象,你就会失去它的生命周期控制,因为容器为你管理它,他的意思是在处理大型xml时它可能容易出错.配置文件.意见不一致,因为您可能有一个测试循环遍历程序集中的每个域对象,然后询问容器是单例,请求范围,会话范围还是应用程序escope.如果它们中的任何一个是真的,它就会失 确保此类问题不会发生的一种方法.

我更倾向于使用域方法(1),因为我看到在控制器级别上重复的代码行节省了很多(当然XML文件中会有更多的行).

我的朋友提出的另一点是,想象一下,由于任何原因,你有义务从di容器A改为B,并且说B不支持构造函数注入(对于一个接缝容器,Java,它操纵BC或者只有通过setter注入完成它的任务),他的观点是,如果我在控制器级别拥有所有代码,我就能够以平滑的方式重构我的代码,因为我可以访问Auto-Refactoring和Auto等工具-Complete,在处理XML文件时不可用.

我坚持这一点,因为我应该立即做出决定.

我应该利用我的架构采用哪种方法？ 还有其他的思维方式吗？

你们真的认为这是一个相关的问题,我应该担心吗？

我正在努力找到找到我的Ninject配置"模块"(指定类型绑定的地方)的最佳位置.我希望我只是错过了一些明显的技巧,因为使用流畅的配置(因此Ninject)开始变成了一个交易破坏者:

在一个包含三个独立项目的简单Web堆栈中:Web,BusinessLogic,DataAccess.我不希望Web层必须直接引用DataAccess层,但我无法看到解决方法,因为:

• 如果我将DataAccess配置模块放在DataAccess层中,我必须引用DataAccess层,这样我就可以在Web层中实例化Ninject内核时访问配置模块

• 如果我将DataAccess配置模块放在Web层中,我必须引用DataAccess层才能访问我想要绑定的类型

• 如果我将DataAccess配置模块放在单独的配置项目中,那么在尝试为web和DataAccess层指定绑定时,我最终会遇到循环引用问题.

IOC的部分好处是允许松散耦合,但据我所知,使用Ninject需要我添加更多我目前拥有的直接项目引用.我错过了什么？