Search Results

Search found 581 results on 24 pages for 'ioc'.

Page 1/24 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Dependency Injection/IoC container practices when writing frameworks

    - by Dave Hillier
    I've used various IoC containers (Castle.Windsor, Autofac, MEF, etc) for .Net in a number of projects. I have found they tend to encourage a number of bad practices. Are there any established practices for IoC container use, particularly when providing a platform/framework? My aim as a framework writer is to make code as simple and as easy to use as possible. I'd rather write one line of code to construct an object than ten or even just two. For example, a couple of code smells that I've noticed and don't have good suggestions to: Large number of parameters (5) for constructors. Creating services tends to be complex; all of the dependencies are injected via the constructor - despite the fact that the components are rarely optional (except for maybe in testing). Lack of private and internal classes; this one may be a specific limitation of using C# and Silverlight, but I'm interested in how it is solved. It's difficult to tell what a frameworks interface is if all the classes are public; it allows me access to private parts that I probably shouldnt touch. Coupling the object lifecycle to the IoC container. It is often difficult to manually construct the dependencies required to create objects. Object lifecycle is too often managed by the IoC framework. I've seen projects where most classes are registered as Singletons. You get a lack of explicit control and are also forced to manage the internals (it relates to the above point, all classes are public and you have to inject them). For example, .Net framework has many static methods. such as, DateTime.UtcNow. Many times I have seen this wrapped and injected as a construction parameter. Depending on concrete implementation makes my code hard to test. Injecting a dependency makes my code hard to use - particularly if the class has many parameters. How do I provide both a testable interface, as well as one that is easy to use? What are the best practices?

    Read the article

  • IOC - Should util classes with static helper methods be wired up with IOC?

    - by Greg
    Hi, Just trying to still get my head around IOC principles. Q1: Static Methods - Should util classes with static helper methods be wired up with IOC? For example if I have a HttpUtils class with a number of static methods, should I be trying to pass it to other business logic classes via IOC? Follow on questions for this might be: Q2: Singletons - What about things like logging where you may typically get access to it via a Logger.getInstance() type call. Would you normally leave this as is, and NOT use IOC for injecting the logger into business classes that need it? Q3: Static Classes - I haven't really used this concept, but are there any guidelines for how you'd typically handle this if you were moving to an IOC based approach. Thanks in advance.

    Read the article

  • can I use the IOC when using a 3rd party library

    - by Greg
    Hi, Q1 If I have a reusable library that is available, that uses interfaces with classes that use the getInstance concept to create concrete classes for you to use, then in this case would that make sense on the client side to use the IOC container to create instances of these classes? Or is that really applying a double layer of abstraction? Q2 Or in the cases where I'm building the reusable library myself and want the client to use an IOC container, then in my reusable library would I then dispense with any overhead of having factories or "getInstance" methods to instantiate the classes in the client? (i.e. as the IOC container would do this no?)

    Read the article

  • Creating an object that is ready to be used & unset properties - with IoC

    - by GetFuzzy
    I have a question regarding the specifics of object creation and the usage of properties. A best practice is to put all the properties into a state such that the object is useful when its created. Object constructors help ensure that required dependencies are created. I've found myself following a pattern lately, and then questioning its appropriateness. The pattern looks like this... public class ThingProcesser { public List<Thing> CalculatedThings { get; set; } public ThingProcesser() { CalculatedThings = new List<Thing>(); } public double FindCertainThing() { CheckForException(); foreach (var thing in CalculatedThings) { //do some stuff with things... } } public double FindOtherThing() { CheckForException(); foreach (var thing in CalculatedThings) { //do some stuff with things... } } private void CheckForException() { if (CalculatedThings.Count < 2) throw new InvalidOperationException("Calculated things must have more than 2 items"); } } The list of items is not being changed, just looked through by the methods. There are several methods on the class, and to avoid having to pass the list of things to each function as a method parameter, I set it once on the class. While this works, does it violate the principle of least astonishment? Since starting to use IoC I find myself not sticking things into the constructor, to avoid having to use a factory pattern. For example, I can argue with myself and say well the ThingProcessor really needs a List to work, so the object should be constructed like this. public class ThingProcesser { public List<Thing> CalculatedThings { get; set; } public ThingProcesser(List<Thing> calculatedThings) { CalculatedThings = calculatedThings; } } However, if I did this, it would complicate things for IoC, and this scenario hardly seems appropriate for something like the factory pattern. So in summary, are there some good guidelines for when something should be part of the object state, vs. passed as a method parameter? When using IoC, is the factory pattern the best way to deal with objects that need created with state? If something has to be passed to multiple methods in a class, does that render it a good candidate to be part of the objects state?

    Read the article

  • Explicitly pass context object versus injecting with IoC

    - by SonOfPirate
    I have a layered service application where the service layer delegates operations into the domain layer for execution. Many of these operations need to know the context under which they are operation. (The context included the identity of the current user, culture information, etc. received from the caller.) For example, I have an API method that returns a list of announcements. The list is based on the current user's role and each announcement is localized to their culture. The API is a thin-facade that delegates to an Application Service in my domain layer. The Application Service method obviously needs to know the context of the current request/operation as another call to the same API from another user should result in a different list. Within this method, we also have logging that uses some of the context information so we a clear understanding of the context when the operation was performed (this is especially useful if something goes wrong.) While this is a contrived example, in the real world, my Application Services will coordinate operations with many collaborative components, any number of them also needing the context information. My choice is to pass the context to the Application Service which would then pass it with any calls to collaborators or have the IoC container satisfy the dependency the Application Service and any collaborators have on the context. I am wondering if it is considered good/bad, best practices/code smell, etc. if I pass the context object as a parameter to the domain methods or if injecting the context via an IoC container is preferred. (EDIT: I should mention that the context object is instantiated per-request.)

    Read the article

  • IoC in MVP Asp.NET

    - by Diego Dias
    Hello, Guys. I'm developing a application using MVP and I have a question about How inject my dependencis in my presenters class. Because my presente receve too an instance of the my view. I thought of create a viewbase and inside it I create my dependencies instances and inject it in my presenter instance. Could also have a HttpModule that intercept the calls to page and then I could inject my dependencies. I have some ideas but none I can inject my view in constructor only I can inject my view in mey presente by property. Someone have any ideas how do you do to inject my dependencies and my view in constructor of the presenter?

    Read the article

  • it is a good approach to implement dependency injection in a desktop app?

    - by luis_laurent
    Well, the thing is that I am just about to create a Desktop App (with .NET windows forms) And now I just wonder if it would be really a wise choise to use any IoC (StructureMap,Ninject,Spring .Net), I have used them before for Asp.Net web applications but what makes me doubt now is the fact that working with windows forms my business entities will persist when I navigate through tabs and unlike than web forms or mvc apps where it would be necesary to inject my business entity for every new request that is performed, I mean this because of the Asp.Net page life cycle where is performed the initialization and controls instantiation. Maybe I am misunderstanding the point of using an IoC, so please tell me what do you think would be a better choise?

    Read the article

  • DI/IoC in Java for a .NET'er used to Castle.Windsor

    - by Ciddan
    Is there a Java DI container that works in a similar way to the most excellent Castle.Windsor container on the .NET side? The Java containers I've had a look at all seem to rely on annotations (Guice) within my services, which I don't dig all that much - I'd like to go POJO all the way if possible. Spring on the other hand can do without the annotations, but it requires a lot of XML. XML configuration != maintainability. One of the really nice things about Castle.Windsor is the wiring you're able to set up in code with Installers, auto wiring based on naming conventions and whatnot. Ideally the container should also support lifecycle management and configuration; i.e. registering components as transient, singleton, pooled etc. Another bonus would be support for interceptors. Any tips would be greatly appreciated.

    Read the article

  • Why is IoC / DI not common in Python?

    - by tux21b
    In Java IoC / DI is a very common practice which is extensively used in web applications, nearly all available frameworks and Java EE. On the other hand, there are also lots of big Python web applications, but beside of Zope (which I've heard should be really horrible to code) IoC doesn't seem to be very common in the Python world. (Please name some examples if you think that I'm wrong). There are of course several clones of popular Java IoC frameworks available for Python, springpython for example. But none of them seems to get used practically. At least, I've never stumpled upon a Django or sqlalchemy+<insert your favorite wsgi toolkit here> based web application which uses something like that. In my opinion IoC has reasonable advantages and would make it easy to replace the django-default-user-model for example, but extensive usage of interface classes and IoC in Python looks a bit odd and not »pythonic«. But maybe someone has a better explanation, why IoC isn't widely used in Python.

    Read the article

  • Examples of IOC/DI over Singleton

    - by Amitd
    Hi, Just started learning/reading about DI and IOC frameworks. Also I read many articles on SO and internet that say that one should prefer DI/IOC over singleton. Can anyone give/link examples of exactly how DI/IOC eliminates/solves the various issues regarding the Singleton pattern? (hopefully code and explanation for better understanding) Also given a system has already implemented Singleton pattern, how to refactor/implement DI/IOC for the same? (any examples for the same?) (Language/Framework no bars..C# would be helpful) Thanks

    Read the article

  • How do I manage disposing an object when I use IoC?

    - by Aval
    How do I manage disposing an object when I use IoC? My case it is Ninject. // normal explicit dispose using (var dc = new EFContext) { } But sometimes I need to keep the context longer or between function calls. So I want to control this behavior through IoC scope. // if i use this way. how do i make sure object is disposed. var dc = ninject.Get<IContext>() // i cannot use this since the scope can change to singleton. right ?? using (var dc = ninject.Get<IContext>()) { } Sample scopes Container.Bind<IContext>().To<EFContext>().InSingletonScope(); Container.Bind<IContext>().To<EFContext>().InRequestScope();

    Read the article

  • IoC and Design Time

    - by benPearce
    I have a WPF application which I am using to learn MVVM and IoC. The problem is that the Model used by one of the Views expects to pull one of its dependancies in the constructor from an IoC container. When working on this View in the Visual Studio designer it cannot show the design because an exception is being raised in the model. Is there a way around this? Am I pulling my dependancies in the wrong place in code or is there a way I can pass in constructed dependancies, perhaps through Constructor injection. At present the IoC container is setup in code in App.xaml.cs. The IoC container is a roll-your-own taken from this article on MSDN - http://msdn.microsoft.com/en-us/magazine/cc337885.aspx

    Read the article

  • Combining MEF and IoC container

    - by Einar Ingebrigtsen
    I primarily use NInject as my IoC container, and is very happy with it - don't want to change that. But some things I want to import using MEF. The thing is, I want the imports to created by the IoC container as the imports can have dependencies to things that I've registered in the NInject IoC. So, my question is: can I import the type of exports in some way, so I can hand it over to NInject for creation or is there an object factory of some kind that I can override in MEF?

    Read the article

  • How do I manage object disposal when I use IoC?

    - by Aval
    My case it is Ninject 2. // normal explicit dispose using (var dc = new EFContext) { } But sometimes I need to keep the context longer or between function calls. So I want to control this behavior through IoC scope. // if i use this way. how do i make sure object is disposed. var dc = ninject.Get<IContext>() // i cannot use this since the scope can change to singleton. right ?? using (var dc = ninject.Get<IContext>()) { } Sample scopes Container.Bind<IContext>().To<EFContext>().InSingletonScope(); // OR Container.Bind<IContext>().To<EFContext>().InRequestScope();

    Read the article

  • Are IoC containers about configuration files?

    - by Jader Dias
    Recently I developed a performance tester console application, with no UI, with the help of a IoC containter (Castle-Windsor-Microkernel). This library enabled me to let the user choose which test(s) to run, simply by changing the configuration file. Have I realized what IoC containers are about? I'm not sure. Even Joel said here on SO that IoC are difficult to understand. From my example, what do you conclude? Am I using IoC container for exactly what they were designed for? Or I am just using one of its secondary features?

    Read the article

  • Will IOC solve our problems?

    - by user127954
    Just trying to implement unit testing into a brownfield type system. Be aware i'm relatively new into the unit testing world. Its going to be a gradual migration of course because there are just so many areas of pain. The current problem i'm trying to solve is we followed a lot of bad practices from our VB6 days and in the conversion of our app to .Net. We have LOT AN LOTS of shared/static functions which call other shared functions and those call others and so on. Sometimes depedencies are passed in as parameters and sometimes they are just newed up within the calling function. I've already instructed our developers to stop creating shared functions and instead create instance members and only use those instance members off of interfaces but that doesn't alleviate the current situation. So you must recursively pass in each and every dependency at the top layer for each function in your code path and method signatures are turning into a mess. I'm hoping this is something that IOC will fix. Currently we are using NUnit/Moq and i'm starting to investigate StructureMap. So far i understand that you pretty much tell StructureMap for x interface i want to default to the concrete class y: ObjectFactory.Initialize(x=>{x.ForRequestType<IInterface>().TheDefaultIsConcreteType<MyClass>()}); Then to runtime: var mytype = ObjectFactory.GetInstance<IInterface>(); the IOC container will initialize the correct type for you. Not sure yet how to swap a fake in for the concrete type but hopefully thats simple. Again will IOC solve the problems i was talking about above? Is there a specific IOC framework that will do it better than StructureMap or can they all handle this situation. Any help would be much appreciated.

    Read the article

  • ASP.NET MVC IoC usability

    - by Andrew Florko
    Hello everybody, How often do you use IoC for controllers/DAL in real projects? IoC allows to abstract application from concrete implementation with additional layer of interfaces that should be implemented. But how often concrete implementation changes? Should we really have to do job twice adding method to interface then the implementation if implementation hardly will ever be changed? I took part in about 10 asp.net projects and DAL (ORM-like and not) was never rewritten completely. Watching lots of videos I clearly understand that IoC "is cool" and the really nice way to program, but does it really needed?

    Read the article

  • overwhelmed by IOC choices

    - by Steve
    There are so many IOC choices, that I don't know where to begin. I've looked at Spring.NET, Unity, Ninject, Windsor, and StructureMap so far, and I have no idea what makes one better than the other. So, what is your favorite IOC, and what feature(s) makes you use it over any other?

    Read the article

  • Why are IOC containers unnecessary with dynamic languages

    - by mikemay
    Someone on the Herding Code podcast No. 68, http://herdingcode.com/?p=231, stated that IOC containers had no place with Python or Javascript, or words to that effect. I'm assuming this is conventional wisdom and that it applies to all dynamic languages. Why? What is it about dynamic languages that makes IOC containers unnecessary?

    Read the article

  • IoC - Dynamic Composition of object instances

    - by Joshua Starner
    Is there a way using IoC, MEF [Imports], or another DI solution to compose dependencies on the fly at object creation time instead of during composition time? Here's my current thought. If you have an instance of an object that raises events, but you are not creating the object once and saving it in memory, you have to register the event handlers every time the object is created. As far as I can tell, most IoC containers require you to register all of the classes used in composition and call Compose() to make it hook up all the dependencies. I think this may be horrible design (I'm dealing with a legacy system here) to do this due to the overhead of object creation, dependency injection, etc... but I was wondering if it was possible using one of the emergent IoC technologies. Maybe I have some terminology mixed up, but my goal is to avoid writing a framework to "hook up all the events" on an instance of an object, and use something like MEF to [Export] handlers (dependencies) that adhere to a very specific interface and [ImportMany] them into an object instance so my exports get called if the assemblies are there when the application starts. So maybe all of the objects could still be composed when the application starts, but I want the system to find and call all of them as the object is created and destroyed.

    Read the article

  • Injecting Dependencies into Domain Model classes with Nhibernate (ASP.NET MVC + IOC)

    - by Sunday Ironfoot
    I'm building an ASP.NET MVC application that uses a DDD (Domain Driven Design) approach with database access handled by NHibernate. I have domain model class (Administrator) that I want to inject a dependency into via an IOC Container such as Castle Windsor, something like this: public class Administrator { public virtual int Id { get; set; } //.. snip ..// public virtual string HashedPassword { get; protected set; } public void SetPassword(string plainTextPassword) { IHashingService hasher = IocContainer.Resolve<IHashingService>(); this.HashedPassword = hasher.Hash(plainTextPassword); } } I basically want to inject IHashingService for the SetPassword method without calling the IOC Container directly (because this is suppose to be an IOC Anti-pattern). But I'm not sure how to go about doing it. My Administrator object either gets instantiated via new Administrator(); or it gets loaded via NHibernate, so how would I inject the IHashingService into the Administrator class? On second thoughts, am I going about this the right way? I was hoping to avoid having my codebase littered with... currentAdmin.Password = HashUtils.Hash(password, Algorithm.Sha512); ...and instead get the domain model itself to take care of hashing and neatly encapsulate it away. I can envisage another developer accidently choosing the wrong algorithm and having some passwords as Sha512, and some as MD5, some with one salt, and some with a different salt etc. etc. Instead if developers are writing... currentAdmin.SetPassword(password); ...then that would hide those details away and take care of those problems listed above would it not?

    Read the article

  • How do I correctly use Unity to pass a ConnectionString to my repository classes?

    - by GenericTypeTea
    I've literally just started using the Unity Application Blocks Dependency Injection library from Microsoft, and I've come unstuck. This is my IoC class that'll handle the instantiation of my concrete classes to their interface types (so I don't have to keep called Resolve on the IoC container each time I want a repository in my controller): public class IoC { public static void Intialise(UnityConfigurationSection section, string connectionString) { _connectionString = connectionString; _container = new UnityContainer(); section.Configure(_container); } private static IUnityContainer _container; private static string _connectionString; public static IMovementRepository MovementRepository { get { return _container.Resolve<IMovementRepository>(); } } } So, the idea is that from my Controller, I can just do the following: _repository = IoC.MovementRepository; I am currently getting the error: Exception is: InvalidOperationException - The type String cannot be constructed. You must configure the container to supply this value. Now, I'm assuming this is because my mapped concrete implementation requires a single string parameter for its constructor. The concrete class is as follows: public sealed class MovementRepository : Repository, IMovementRepository { public MovementRepository(string connectionString) : base(connectionString) { } } Which inherits from: public abstract class Repository { public Repository(string connectionString) { _connectionString = connectionString; } public virtual string ConnectionString { get { return _connectionString; } } private readonly string _connectionString; } Now, am I doing this the correct way? Should I not have a constructor in my concrete implementation of a loosely coupled type? I.e. should I remove the constructor and just make the ConnectionString property a Get/Set so I can do the following: public static IMovementRepository MovementRepository { get { return _container.Resolve<IMovementRepository>( new ParameterOverrides { { "ConnectionString", _connectionString } }.OnType<IMovementRepository>() ); } } So, I basically wish to know how to get my connection string to my concrete type in the correct way that matches the IoC rules and keeps my Controller and concrete repositories loosely coupled so I can easily change the DataSource at a later date.

    Read the article

  • DDD and IOC Containers

    - by MegaByte
    Hi Im fairly new with DDD and Im trying to use IOC in order to loosen up my tightly coupled layers :) My C# web application consists of a UI, domain and persistence layer. My persistence layer references my domain layer and contains my concrete repository implementations and nhibernate mappings. Currently my UI references my domain layer. My question : How do I use an IOC container to inject my concrete classes, in my persistence layer, into my domain layer? Does this meen that my UI should also reference my persistence layer?

    Read the article

  • Autowiring collections with IoC

    - by Marcus
    Hi, Anyone know if there exists any IoC container that can handle this: Given: ISomeInterfce<T> where T : Entity Impl1 : ISomeInterfce<Entity1> Impl2 : ISomeInterfce<Entity1> Impl3 : ISomeInterfce<Entity2> Impl4 : ISomeInterfce<Entity2> I want to be able to auto wire my system and be able to resolve like this IoC.ResolveAll(typeof(ISomeInterfce<Entity1>)) and get a collection back of all implementations of ISomeInterfce<Entity1>

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >