Tag: 反转控制

IoC vs库中的全局变量: 所以说我的类型在构造函数中有一些参数，如下所示： public MyType(IComObject wrapper,string table) {} 现在IComObject是两个不同COM对象的包装器。我的所有类型（90％）都必须使用IComObject，因此以良好的DI方式（允许测试）我将IComObject传递给需要它的每种类型。主要的问题是当有人去使用我的COM包装器库时，必须将IComObject的一个实例传递给他们所做的一切，这使得代码有点难以管理和维护。我想知道是否应该使用IoC容器或用户可以设置的全局变量，以便它们不必传递IComOject实例。例： public MyType(string table) : this(IoC.Resolve,table) {} 要么 public MyType(string table) : this(StaticClass.ComInstance,table) {} 这样用户就可以这样做： //Set up Ioc container COMObject object = new COMObject(); Ioc.Register(typeof(IComObject),object); MyType mytype = new MyType(“test.tab”); 要么 COMObject object = new COMObject(); StaticClass.ComInstance = object; MyType mytype = new MyType(“test.tab”); 在这种情况下你认为我该怎么做？

Unity：在xml配置文件中将参数传递给自定义生命周期构造函数: 我写了这样的CustomLifetimeManager： public class CustomLifetimeManager : LifetimeManager { private readonly string _arg; public CustomLifetimeManager(string arg) { _arg = arg; } } 现在，它可以通过编程方式轻松配置容器，但如何将其添加到配置文件中，如下所示？

关于generics类的Unity 2.0 IOC配置: 我想要一些Repository类扩展一个常见的generics类来执行一些常见的操作，问题是：如何在配置文件中配置UserExRepository类型。 public class UserExRepository : Repository, IUserEx { public UserExRepository(Context context):base(context){ } } public abstract class Repository : IRepository where TObject : class { protected Context Context = null; public Repository(Context context) { Context = context; } // do some common operation about entity, like create, delete… }

复杂服务层中IoC的最佳实践: 我正在开发一个MVC应用程序，我正在使用Unity for IoC。我的应用程序基本上由UI层，服务层和存储库层组成。我的典型控制器是： public class TestController : Controller { private ITestService testServ; public TestController(ITestService _testServ) { testServ= _testServ; } public ActionResult Index() { testServ.DoSomething(); return View(); } } 没有什么不寻常的，我的每个控制器都注入了一个服务对象。因此，我的服务层对象执行复杂的业务规则，聚合来自许多不同存储库的信息。通过使用IoC我发现我的构造函数看起来过于复杂，但由于服务需要访问许多存储库，我无法看到任何解决方法。我的服务层中的典型类看起来像： public class TestService : ITestService { private ITransactionRepository transRepo; private IAccountRepository accountRepo; private ISystemsRepository sysRepo; private IScheduleRepository schRepo; private IProfileRepository profileRepo; […]

dependency injection初始化: 请注意：我刚开始使用AutoFac来了解DI和IoC。 dependency injection应该在控制器构造函数中初始化吗？这怎么样？ private IMyService iMyService; public HomeController(IMyServices myService) { iMyService = myService; } 不同于… public IMyService iMyService = new MyService(); 最后，似乎依赖性仍然存在。编辑：修正了拼写错误，新的MyService（）; 是新的IMyService（）;

基类中的构造函数dependency injection: 我正在使用Entity Framework构建存储库基类，其中所有实体存储库都将inheritance。我想使用Ninject使用dependency injection在基类中注入DatabaseContext 。我认为构造函数注入是正确的方法，但在派生类I中使用构造函数注入执行此操作必须将参数传递给基类中的构造函数，我不想要它。因此，Setter Injection更合适吗？这是我的代码： public abstract class BaseRepository : IDisposable where TEntity : class { private readonly DatabaseContext _databaseContext; protected BaseRepository(DatabaseContext databaseContext) { this._databaseContext = databaseContext; } } 在上面的例子中使用构造函数注入，在我的派生类中，我必须将databaseContext对象传递给基类，我不喜欢对我的所有派生类执行此操作： public class UsuarioRepository : BaseRepository, IUsuarioRepository { public UsuarioRepository(DatabaseContext databaseContext) : base(databaseContext) { } } Setter Injection而不是Constructor Injection是解决这个问题的好方法吗？什么是最好的方法？ […]

使用IoC时，unit testing的策略应该是什么？: 毕竟我读过有关dependency injection和IoC的内容我已经决定尝试在我们的应用程序中使用Windsor Container（它是一个50K LOC多层Web应用程序，所以我希望它不是一个矫枉过正）。我已经使用了一个简单的静态类来包装容器，并在启动应用程序时对其进行初始化，这对于现在来说非常好。我的问题是关于unit testing。我知道通过让我可以将类协作者的存根/模拟实现注入到被测试的类中，DI将使我的生活变得更加轻松。我已经使用这种技术编写了几个测试，这似乎对我有意义。我不确定的是我是否应该在unit testing中使用IoC（在本例中为Windsor Castle）（可能以某种方式将其配置为针对我的特殊情况返回存根/模拟）或者是否更好地连接所有依赖项在测试中手动。你怎么想，什么做法对你有用？

如何配置unity容器来提供字符串构造函数值？: 这是我dad课 public class Dad { public string Name { get;set; } public Dad(string name) { Name = name; } } 这是我的测试方法 public void TestDad() { UnityContainer DadContainer= new UnityContainer(); Dad newdad = DadContainer.Resolve(); newdad.Name = “chris”; Assert.AreEqual(newdad.Name,”chris”); } 这是我得到的错误 “InvalidOperationException – the type String cannot be constructed. You must configure the container to supply this […]

记录为装饰器与dependency injection – 如果我需要在类中登录，该怎么办？: （我最初在这篇评论中提到了这个问题，但Mark Seemann要求我创建一个新问题。）我正在开始一个新的应用程序（.NET Core，如果这很重要），现在我正在尝试决定如何准确地进行日志记录。普遍的共识似乎是日志记录是一个跨领域的问题，因此记录器不应该直接注入应该记录的类。通常，有一个例如下面的类如何不这样做： public class BadExample : IExample { private readonly ILogger logger; public BadExample(ILogger logger) { this.logger = logger; } public void DoStuff() { try { // do the important stuff here } catch (Exception e) { this.logger.Error(e.ToString()); } } } 相反，具有业务逻辑的类不应该知道记录器（ SRP ），并且应该有一个单独的类来执行日志记录： public class BetterExample : IExample { public […]

在跨平台（Xamarin）应用程序中使用哪种IoC continer？: 我正在ASP.NET中为Windows，OSX，iOS，Windows Mobile，Android和Web构建跨平台应用程序。对于每个客户端我都使用C＃（我正在使用Xamarin）。单一VS解决方案中的一切。我的核心代码（域）在类库（可移植）中，因此可以在每个UI（客户端）中使用。我想在该项目中使用IoC容器，这是我的问题：我不知道我会选择IoC，是否适用于每个客户端。我知道例如Ninject在便携式类库中不起作用 – 这样的项目有Ninject.Portable 。这让我想到，我选择的IoC可能无法在我的一个客户端工作，这将是不好的。所以，我的问题是：在Visual Studio 2015中可以在便携式类库和每个客户端（UI）中使用哪些IoC容器？我对Simple Injector感兴趣，但现在我有这些疑虑。