ASP.NET

27-Feb-11 8:59

I'm fairly new to dependency injection but it seems like a proper DI implementation will be fairly complex.

For example, DI requires a centralized class that manages the configuration and resolves the dependencies at runtime.

DI is also based on the concept of using interfaces. For example, a SpecialLogger should use an ILogger interface.

The centralized DI manager class will need to register types - for example, associate ILogger to SpecialLogger.

SpecialLogger will also need to implement the ILogger interface so SpecialLogger can be used through the DI ILogger interface.

Therefore, it seems like a sln using DI will need multiple projects to support DI. Here is an example for logging:

* MyCompany.MyDivision.Framework.DI.Management - this would have the DI manager where dependency types are registered and resolved at runtime
* MyCompany.MyDivision.Framework.Logging - this would have the implementation of a logging class. The main logging class would need to implement ILogger.
* MyCompany.MyDivision.Framework.DI.Interfaces - this would have the ILogger interface.

Interfaces would need to be stored in a separate class library from the DI manager because both the DI manager and SpecialLogger use the ILogger interface. Since the DI manager associates SpecialLogger to ILogger a circular reference would be encountered without a separate class library to store the ILogger interface.

Does this sound like a reasonable assessment? Like I said I am just learning DI so if you can share any real-world experience with a DI implementation that would be appreciated.

James Simpson28-Feb-11 3:57

James Simpson

28-Feb-11 3:57

The DI framework is usually a component of the application layer (in my experience) e.g If you had an ASP.NET MVC App and you were using structure map, its your front end application that would reference structure map, the rest of your code below that stack does not need to know about the DI container becuase its dependencies would be resovled by the main application (E.g MVC)

Then the rest of your dependencies etc.. you could seperate the interfaces from the concrete classes, but I would only do that when its required. You could start with a simple MyCompany.MyDivision.Framework.Logging project that contains the ILogger and the SpecialLogger.

Becuase the DI container is just references in the top of the stack (e.g the MVC app) it already has references to the components below it, so no circular reference is created.

If you find yourself reference the DI container lower down the stack then you may run into problems, there are usually more specific services you can implement for resolving things the DI container could provide.

e.g Lets Say you had the Logging assebly, a Domain Layer assembly, and a front end project, and the requirements where for the front end project to have references to the domain layer and logger, but you dont want interdependencies between the two:

Then lets imagine you had a bunch of repositories that needed resolving in your domain data access layer, that could be a IRepositoryRegistry interface, but it could be implemented in the app up the stack to look at the DI container to return a repository. There would be no need for your logging assembly to ever use IRepositoryRegistry, so you don't end up with dependencies between those sort of assemblies.

James

James Simpson
Web Solutions Developer
www.methodworx.com

Member 391904928-Feb-11 19:21

28-Feb-11 19:21

So just using a very simple example. I would create the UnityContainer and register the FileLogger like this:

UnityContainer uc = new UnityContainer();
uc.RegisterType<ILogger, FileLogger>();

Then in the same code block I would resolve the ILogger for the dependent classes like this for an Order class:

uc.Resolve<Order>();

To do this I would need to define an Logger property on the order class like this right?:

public ILogger Logger { get; set; }

From what you are saying it sounds like an important design goal of dependency injection is that a central class does all of the injection and the classes being injected should not need to know about the container. Is this correct?

Member 391904928-Feb-11 20:01

28-Feb-11 20:01

I got the example in my above post to work.

Basically, uc.Resolve<order>() returns an Order object with the Order ILogger set to FileLogger.

This is great but how can I persist this dependency?

In the following example I would expect the FileLogger to be persisted as the ILogger to be used for all instances of the Order object:

UnityContainer uc = new UnityContainer();
uc.RegisterType<ILogger, FileLogger>();
uc.Resolve<Order>();

Order o = new Order();
ILogger logger = o.Logger;

However, in this example, although the FileLogger is associated with the object returned from the Resolve<order> method, the subsequent Order instantiation does not have a reference to FileLogger (null).

This seems to reflect the most typical scenario because the DI should be done once and then code within the Order object will run independently and try to access the Logger from within the Order object.

Are there some sort of settings that I'm missing to be able to persist this configuration?

James Simpson28-Feb-11 22:55

James Simpson

28-Feb-11 22:55

In the example you provided you are not initializing the Order class via the container.

uc.Resolve<order>() creates an instance of the Order and then resolves its dependencies

This is why you would end up with more specialized services to initialize the objects, that are typically implemented with the container.

e.g Lets, say Order is an Entity in a domain model, you have several options about how you initialize a new one, a typical way is to have a factory, e.g IOrderFactory.Create(). Lets say for the sake of argument you are using ASP.NET and you are using dependency injection to initialize your controller paramerters via a custom controller factory (if you are unsure about that, basically a DI container is supplying dependencies to Controllers)

You would have a dependency to IOrderFactory in your controller constructor which would implement create as:

return uc.Resolve<order>();

Your order factory would be injected to your controller, and you can call orderFactory.Create() to get a new instance.

Or..

Inject the DI container into your controllers and just always call .Resolve. But I dont like to know about the DI container anywhere in my code, I prefer to have proper named services. e.g IOrderFactory is explicit, it is a Factory for creating Order objects, but by just handing a reference to your DI container everywhere you are actually hiding the dependencies. (e.g from the constructor parameters, it is not obvious what dependencies are going to be used and why)

Also - (off topic), with the example you specified above, if Order is an entity in your domain model, and you are attempting to add logging functionality to it, it is better to use a Dynamic Proxy pattern to acheive this (or) Aspect Orientated programming. It is not a dependency of the Order object to have logging functionality, it is more likely a dependency of your infrasturcture. So rather than cluttering up your order object with stuff it does not need, you can inject a Logging mechanism transparently using something like Castle Dynamic Proxy (?) You will still need to get the object from some sort of factory, but it will make your classes much cleaner.

James Simpson
Web Solutions Developer
www.methodworx.com

Member 39190491-Mar-11 8:44

1-Mar-11 8:44

Thanks James - You know your stuff

Member 39190491-Mar-11 9:07

1-Mar-11 9:07

Hi James - This is the solution that you provided in your last post:

"You would have a dependency to IOrderFactory in your controller constructor which would implement create as: return uc.Resolve();"

Can you please provide a constructor code block for this?

This is the closest constructor I can infer from your post:

public OrderController(IOrderFactory creator)
{
uc.Resolve();
}

1. The factory does the class creation but it's included as a param. So there is another layer of abstraction that sets the appropriate IOrderFactory? What is this additional layer of abstraction and where is it located?
2. So uc.Resolve() should be used to resolve the domain objects used by the controller? I'm assuming that the dependencies are passed down through the interface param?

I'm still trying to figure out the pieces and interaction for this.

James Simpson1-Mar-11 10:02

James Simpson

1-Mar-11 10:02

I think my examples are probably more confusing than they should be. if you develop your layers without thinking about the DI layer, just rely on getting dependencies into objects via a constructor, you can add the DI container later.

Typically the container would resolve the controller (transparent to your code) and inject an instance of a factory, or repository, or service.. or whatever is needed
Then in the example of the IOrderFactory, the create could also be implemented to resolve the Order object from the same container

But, if the Order is an Entity you should be using a IOrderRepository to manipulate it, and this can include the factory method Create()

The key is to not architect your layers with the DI container in mind, just use the right sort of services to get the job done, at the end of the day they *might* be implemented using a DI container, they might not... if you working with this sort of technology your probably trying to unit test too, so if you get this right, it will probably lead you down the right path anyway.

Google sturcture map ASP.NET MVC implementation there are some good articles that demonstrate the idea behind a simple DI container and MVC.

Good luck

James

James Simpson
Web Solutions Developer
www.methodworx.com

payment processor - your experience

Spectre_0013-Mar-11 2:03

Spectre_001

3-Mar-11 2:03

While not incorrect by any means, IoC/DI can be as simple as:

/*
 * Simple Inversion of Control/Dependency Injection
 */

using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Text;
using System.Configuration;
using USCG_SSO.Interfaces;

namespace USCG_SSO
{
    public class ObjectFactory<T> : IObjectFactory<T>
    {
        public ObjectFactory() { }

        // Create an instance of an object
        public T getInstance()
        {
            return getInstance(null);
        }

        // Overload create instance of an object using creation parameters
        public T getInstance(object[] initializationParameters)
        {
            NameValueCollection appSettings = ConfigurationManager.AppSettings;
            Type type = Activator.CreateInstance(typeof(T), initializationParameters).GetType();
            // Any special initialization for an object should be placed in a case statement
            // using that object's fully qualified type name
	    if (initializationParameters == null)
	    {
		switch (type.ToString())
		{
		    case "USCG_SSO.ServiceUser":
			NameValueCollection appSettings = ConfigurationManager.AppSettings;
			initializationParameters = new object[]
			{
			    appSettings["ADUserID"],
			    appSettings["ADUserPassword"],
			    appSettings["ADFieldName"]
			}
	                break;
		    case "USCG_SSO.ActiveDirectory"
			initializationParameters = new object[]
			{
			    new ObjectFactory<ServiceUser>().getInstance(),
			    new ObjectFactory<CurrentUser>().getInstance()
			}
			break;
		    default:
			break;
		}
	    }
            return (T)Activator.CreateInstance(typeof(T), initializationParameters);
        }
    }
}

Assuming: USCG_SSO.ActiveDirectory object requires a ServiceUser object and a CurrentUser object to be passed in it's constructor, and USCG_SSO.ServiceUser object requires values retreived from the .config file in it's constructor. If you call

IActiveDirectory ADObject = new ObjectFactory<ActiveDirectory>().getInstance();

You would obtain an ActiveDirectory object complete with all of it's dependencies. Now, granted, this isn't as "fancy" or extensible as an actual IoC framework (there's no registration of dependencies, auto-resolution, etc.), it is, however, a complete, very simple IoC/DI implementation.

Kevin Rucker, Application Programmer
QSS Group, Inc.
United States Coast Guard OSC
Kevin.D.Rucker@uscg.mil

"Programming is an art form that fights back." -- Chad Hower

Jassim Rahma26-Feb-11 20:55

Jassim Rahma

26-Feb-11 20:55

Hi,

I would like to know if you processed credit card payment on your ASP.NET website or one of your clients ASP.NET website..

which company you used to do it? did they have ASP.NET API?

which payment processor your recommend?

Abhijit Jana26-Feb-11 22:18

Abhijit Jana

26-Feb-11 22:18

You can use PayPal API for processing. In code Project there are several good article which explained how to use the API's of Paypal !
Use of the PayPal payment system in ASP.NET[^]
http://beta.codeproject.com/KB/aspnet/paypal_c_aspnet.aspx[^]

Hope this will help you ! Thumbs Up | :thumbsup:

Cheers !
Abhijit Jana | My Blog | @Twitter | Daily .Net Tips

Jassim Rahma3-Mar-11 1:12

Jassim Rahma

3-Mar-11 1:12

but the problem with Paypal, they don't allow international uses.. it's only for US as they told me in their email sent to me.

N a v a n e e t h27-Feb-11 2:56

N a v a n e e t h

27-Feb-11 2:56

jrahma wrote:
did they have ASP.NET API?

Usually no one will provide .NET specific APIs. It will be web services which can be invoked using wide variety of programming languages.

Best wishes,
Navaneeth