Develop Reference

Difference between unity container and unit of work (MVC)

What is the difference between unity container and unit of work(if there is any), as I understand both are doing same thing, but how to determine which one to use.
I need to be sure, that I understand it well and there is no any difference.

Unity is an inversion of control container, where inversion of control is a design pattern, and unit of work is another design pattern...
The main difference between the two is they're absolutely different design patterns, there's no criteria to match both patterns and find out similarities.
OP said...
I didn't know about inversion of control, read that link and have done
some search, but still both are related with dependency injection and
no one uses combination of them(both of it), they are using just one
of them
Dependency injection is an approach to inversion of control.
In the other hand, unit of work has nothing to do with inversion of control or dependency injection. Again, unit of work and inversion of control/dependency injection are different design patterns.
Perhaps you can inject dependencies in an unit of work, or inject an unit of work somewhere to decouple your architecture from the concrete implementation of the so-called unit of work. There's a big difference from comparing two design patterns from just understanding that design patterns can cooperate to build a software stack.

Your Ioc container, unity, may or may not contain a hard implementation at the other end that is using unit of work. You will implement your interfaces using some specific class that satisfies your generic interface definitions but using a specific backing store such as Entity Framework, LinqToSql, Ado Sql Commands, test stubs, etc.. Unit of work would not be applicable if you are using Ado sql commands so it is usually a good idea to only include generic functionality in your ioc "service contracts".

mocking in unit tests with dependency injection

I am wondering about the best way to make my system testable.
I am unsure of the best practice with DI and mocking.
If DI is facilitated by using interfaces should i build mock classes which implement the same interface as the real classes?
And then use these mock classes in my tests via DI?
I importing data into HDInsight. The data is taken from azure queues.
I want to mock/emulate both the queue and the hdinsight so my unit tests are fast and decoupled.
Should i use dependency injection in my tests or is moq sufficient, are these supposed to operate independently?

Mocks and Dependency Injection go hand in hand because without dependency injection, you would not be able to have your classes use the mocks instead of the real thing. What you don't need is a Dependency Injection Container (like Ninject for example). You can use it if you like, but if you did it right, you should be able to Unit-Test your classes by supplying all dependencies yourself.

Moq is sufficient.
Your tests use the mocks to help facilitate results. They are quick and easy to setup (once you are used to whatever mocking library you choose).
If you were to utilize a DI framework.. you would be tripling your workload. Not only are you manually stubbing out mocks.. but you are also then maintaining your DI configuration for your tests. This simply wouldn't fit nicely into any workflow.

Is testability alone justification for dependency injection?

The advantages of DI, as far as I am aware, are:
Reduced Dependencies
More Reusable Code
More Testable Code
More Readable Code
Say I have a repository, OrderRepository, which acts as a repository for an Order object generated through a Linq to Sql dbml. I can't make my orders repository generic as it performs mapping between the Linq Order entity and my own Order POCO domain class.
Since the OrderRepository by necessity is dependent on a specific Linq to Sql DataContext, parameter passing of the DataContext can't really be said to make the code reuseable or reduce dependencies in any meaningful way.
It also makes the code harder to read, as to instantiate the repository I now need to write
new OrdersRepository(new MyLinqDataContext())
which additionally is contrary to the main purpose of the repository, that being to abstract/hide the existence of the DataContext from consuming code.
So in general I think this would be a pretty horrible design, but it would give the benefit of facilitating unit testing. Is this enough justification? Or is there a third way? I'd be very interested in hearing opinions.

Dependency Injection's primary advantage is testing. And you've hit on something that seemed odd to me when I first started adopting Test Driven Development and DI. DI does break encapsulation. Unit tests should test implementation related decisions; as such, you end up exposing details that you wouldn't in a purely encapsulated scenario. Your example is a good one, where if you weren't doing test driven development, you would probably want to encapsulate the data context.
But where you say, Since the OrderRepository by necessity is dependent on a specific Linq to Sql DataContext, I would disagree - we have the same setup and are only dependent on an interface. You have to break that dependency.
Taking your example a step further however, how will you test your repository (or clients of it) without exercising the database? This is one of the core tenets of unit testing - you have to be able to test functionality without interacting with external systems. And nowhere does this matter more than with the database. Dependency Injection is the pattern that makes it possible to break dependencies on sub-systems and layers. Without it, unit tests end up requiring extensive fixture setup, become hard to write, fragile and too damn slow. As a result - you just won't write them.
Taking your example a step farther, you might have
In Unit Tests:
// From your example...
new OrdersRepository(new InMemoryDataContext());
// or...
IOrdersRepository repo = new InMemoryDataContext().OrdersRepository;
and In Production (using an IOC container):
// usually...
Container.Create<IDataContext>().OrdersRepository
// but can be...
Container.Create<IOrdersRepository>();
(If you haven't used an IOC container, they're the glue that makes DI work. Think of it as "make" (or ant) for object graphs...the container builds the dependency graph for you and does all of the heavy lifting for construction). In using an IOC container, you get back the dependency hiding that you mention in your OP. Dependencies are configured and handled by the container as a separate concern - and calling code can just ask for an instance of the interface.
There's a really excellent book that explores these issues in detail. Check out xUnit Test Patterns: Refactoring Test Code, by Mezaros. It's one of those books that takes your software development capabilities to the next level.

Dependency Injection is just a means to an end. It's a way to enable loose coupling.

Small comment first: dependency injection = IoC + dependency inversion. What matter the most for testing and what you actually describe, is dependency inversion.
Generally speaking, I think that testing justifies dependency inversion. But it doesn't justify dependency injection, I wouldn't introduce a DI container just for testing.
However, dependency inversion is a principle that can be bended a bit if necessary (like all principles). You can in particular use factories in some places to control the creation of object.
If you have DI container, it's what happens automatically; the DI container act as a factory and wires the object together.

The beauty of Dependency Injection is the ability to isolate your components.
One side-effect of isolation is easier unit-testing. Another is the ability to swap configurations for different environments. Yet another is the self-describing nature of each class.
However you take advantage of the isolation provided by DI, you have far more options than with tighter-coupled object models.

The power of dependency injection comes when you use an Inversion of Control container such as StructureMap. When using this, you won't see a "new" anywhere -- the container will take control of your object construction. That way everything is unaware of the dependencies.

I find that relationship between needing Dependency Injection container and testability is the other way around. I find DI extremely useful because I write unit testable code. And I write unit testable code because it's inherently better code- more loosely coupled smaller classes.
An IoC container is another tool in the toolbox that helps you manage complexity of the app - and it works quite well. I found it allows to better to code to an interface by taking instantiation out of the picture.

The design of tests here always depends on SUT (System Under Test). Ask yourself a question - what do I want to test?
If yours repository is just accessor to the database - then it is needed to test it like accessor - with database involvement. (Actually such kind of tests are not unit tests but integration)
If yours repository performs some mapping or business logic and acts like accessor to the database, then this is the case when it is needed to do decomposition in order to make your system to comply with SRP (Single Responsibility Principle). After decomposition you will have 2 entities:
OrdersRepository
OrderDataAccessor
Test them separately from each other, breaking dependencies with DI.
As of constructor ugliness... Use DI framework to construct your objects. For example with using Unity your constructor:
var repository = new OrdersRepository(new MyLinqDataContext());
will be look like:
var repository = container.Resolve<OrdersRepository>;

The jury is still out for me about the use of DI in the context of your question. You've asked if testing alone is justification for implementing DI, and I'm going to sound a little like a fence-sitter in answering this, even though my gut-response is to answer no.
If I answer yes, I am thinking about testing systems when you have nothing you can easily test directly. In the physical world, it's not unusual to include ports, access tunnels, lugs, etc, in order to provide a simple and direct means of testing the status of systems, machines, and so on. This seems reasonable in most cases. For example, an oil pipeline provides inspection hatches to allow equipment to be injected into the system for the purposes of testing and repair. These are purpose built, and provide no other function. The real question though is if this paradigm is suited to software development. Part of me would like to say yes, but the answer it seems would come at a cost, and leaves us in that lovely grey area of balancing benefits vs costs.
The "no" argument really comes down to the reasons and purposes for designing software systems. DI is a beautiful pattern for promoting the loose coupling of code, something we are taught in our OOP classes is a very important and powerful design concept for improving the maintainability of code. The problem is that like all tools, it can be misused. I'm going to disagree with Rob's answer above in part, because DI's advantages are NOT primarily testing, but in promoting loosely coupled architecture. And I'd argue that resorting to designing systems based solely on the ability to test them suggests in such cases that either the architecture is is flawed, or the test cases are inappropriately configured, and possibly even both.
A well-factored system architecture is in most cases inherently simple to test, and the introduction of mocking frameworks over the last decade makes the testing much easier still. Experience has taught me that any system that I found hard to test has had some aspect of it too tightly coupled in some way. Sometimes (more rarely) this has proven to be necessary, but in most cases it was not, and usually when a seemingly simple system seemed too hard to test, it was because the testing paradigm was flawed. I've seen DI used as a means to circumvent system design in order to allow a system to be tested, and the risks have certainly outweighed the intended rewards, with system architecture effectively corrupted. By that I mean back-doors into code resulting in security problems, code bloated with test-specific behaviour that is never used at runtime, and spaghettification of source code such that you needed a couple of Sherpa's and a Ouija Board just to figure out which way was up! All of this in shipped production code. The resulting costs in terms of maintenance, learning curve etc can be astronomical, and to small companies, such losses can prove to be devastating in the longer term.
IMHO, I don't believe that DI should ever be used as a means to simply improve testability of code. If DI is your only option for testing, then the design usually needs to be refactored. On the other hand, implementing DI by design where it can be used as a part of the run-time code can provide clear advantages, but should not be misused as it can also result in classes being misused, and it should not be over-used simply because it seems cool and easy, as it can in such cases over-complicate the design of your code.
:-)

It's possible to write generic data access objects in Java:
package persistence;
import java.io.Serializable;
import java.util.List;
public interface GenericDao<T, K extends Serializable>
{
T find(K id);
List<T> find();
List<T> find(T example);
List<T> find(String queryName, String [] paramNames, Object [] bindValues);
K save(T instance);
void update(T instance);
void delete(T instance);
}
I can't speak for LINQ, but .NET has generics so it should be possible.

What should be the strategy of unit testing when using IoC?

After all what I have read about Dependency Injection and IoC I have decided to try to use Windsor Container within our application (it's a 50K LOC multi-layer web app, so I hope it's not an overkill there). I have used a simple static class for wrapping the container and I initialize it when starting the app, which works quite fine for now.
My question is about unit testing. I know that DI is going to make my life much easier there by giving me the possibility of injecting stub / mock implementations of class collaborators to the class under test. I have already written a couple of tests using this technique and it seems to make sense for me. What I am not sure about is whether I should be using IoC (in this case Windsor Castle) also in unit tests (probably somehow configure it to return stubs / mocks for my special cases) or is it better to wire-up all the dependencies manually in the tests. What do you think and what practice has worked for you ?

You don't need DI container in unit tests because dependencies are provided through mock objects generated with frameworks such as Rhino Mocks or Moq. So for example when you are testing a class that has a dependency on some interface this dependency is usually provided through constructor injection.
public class SomeClassToTest
{
private readonly ISomeDependentObject _dep;
public SomeClassToTest(ISomeDependentObject dep)
{
_dep = dep;
}
public int SomeMethodToTest()
{
return _dep.Method1() + _dep.Method2();
}
}
In your application you will use a DI framework to pass some real implementation of ISomeDependentObject in the constructor which could itself have dependencies on other objects while in a unit test you create a mock object because you only want to test this class in isolation. Example with Rhino Mocks:
[TestMethod]
public void SomeClassToTest_SomeMethodToTest()
{
// arrange
var depStub = MockRepository.CreateStub<ISomeDependentObject>();
var sut = new SomeClassToTest(depStub);
depStub.Stub(x => x.Method1()).Return(1);
depStub.Stub(x => x.Method2()).Return(2);
// act
var actual = sut.SomeMethodToTest();
// assert
Assert.AreEqual(3, actual);
}

I'm working on an ASP.NET MVC project with about 400 unit tests. I am using Ninject for dependency injection and MBUnit for testing.
Ninject is not really necessary for unit testing, but it reduces the amount of code I have to type. I only have to specify once (per project) how my interfaces should be instantiated as opposed to doing this every time I initialize the class being tested.
In order to save time on writing new tests, I have created test fixture base classes with as much generic setup code as possible. The setup procedures in those classes intialize fake repositories, create some test data and a fake identity for the test user. Unit tests only initialize data that is too specific to go into generic setup procedures.
I am also mocking objects (as opposed to faking) in some tests, but I found that faking data repositories results in less work and more accurate tests.
For example, it would be more difficult to check if the method under test I properly commits all updates to the repository after making them when using a repository mock than when I am using a repository fake.
It was quite a bit of work to set up at the beginning, but really helped me reduce save a lot of time in the long run.

I've just written a very similar style and size app. I wouldn't put any dependency injection in the unit tests because it is not complicated enough to be necessary. You should use a mocking framework to create your mocks (RhinoMocks / Moq).
Also Automocking in Moq or the Auto Mock Container in Rhinomocks will simplify building your mocks further.
Auto mocking allows you to get object
of the type you want to test without
setting up mocks by hand. All
dependencies are mocked automatically
(assuming they are interfaces) and
injected into the type constructor. If
you need to you can set up expected
behavior, but you don't have to.

As Darin has already pointed out, you don't need to use DI if you have mocks. (However, DI has a few other benefits as well, including, first of all, lessening dependencies in your code, which makes your code much easier to maintain and extend in the long run.)
I personally prefer wiring up everything in my unit tests, thus relying as little as possible on external frameworks, config files etc.

Mocking without IoC or Dependency Injection

Is there a way to use mocks or fakes in your unit tests without having to use dependency injection or inversion or control?
I found this syntax can be used with TypeMock Isolator (http://learn.typemock.com/). It is a comercial product though, so I was hoping that other frameworks (such as RhinoMocks) would be introducing such syntax at some stage.
/// Can mock objects WITHOUT DEPENDENCY INJECTION.
var hand = Isolate.Fake.Instance<Hand>();
var mouth = Isolate.Fake.Instance<Mouth>();
Isolate.Swap.NextInstance<Hand>().With(hand);
Isolate.Swap.NextInstance<Mouth>().With(mouth);
...
//notice we're not passing the mocked objects in.
var brain = new Brain();
brain.TouchIron(iron);
...
This is very attractive to me this type of syntax, it all happens automatically. We can create a brain there with no required dependencies being passed in and the mocking framework will substitute the dependencies automatically for the mock objects. Any body seen this type of thing anywhere else?
The brain class constructor looks like this now using the above syntax,
public Brain()
{
_hand = new Hand();
_mouth = new Mouth();
}
Whereas the dependency injection example would look like this,
public Brain(IHand hand, IMouth mouth)
{
_hand = hand;
_mouth = mouth;
}
Thanks.

If you have a choice, you should almost always expose a constructor to allow dependencies to be injected. You could still keep the convenience constructor (though some would argue that you shouldn't):
public Brain() : this(new Hand(), new Mouth()) { }
That said, in addition to Isolator you could check out the latest builds of Pex (0.17), which include moles that provide a mechanism similar to Isolator's Swap.

Personally I don't think this is a good thing.
To me, DI provides more good than just testability, so it is unreasonable to go from it even if some tool allows doing it. See also this question and the first answer to it.

AFAIK, TypeMock is the only framework that allows this scenario, and probably will be for a long time. The reason is that it uses a radically different approach to mocking.
All other mocking frameworks use dynamic type creation to do the same thing that you could do in code: extrand and override. In this case, manual and dynamic mocks are basically the same thing, because the they rely on being able to extend abstract types.
TypeMock uses a radically different technique, because it uses the (unmanaged) .NET Profiling API to intercept calls to any type. This is much harder to implement, so it shouldn't be surprising that it is a commercial undertaking.
In any case, TypeMock vs. the rest of the world is an old and very lively debate. Here's one take on it (be sure to also read the comments).

Moles, a detour framework that ships with Pex, also allows to do this... but with a different syntax.
MHand.New = (me) => {
new MHand(me) {
TouchIronIron = iron => {}
};
};
Note that your example is inconsistent.

Thanks for that. It has given me heaps to think about. I am working on an app that has not been designed for testing and currently does not have unit tests. I think the final solution will be to restructure it gradually, and use Rhino Mocks. I have used Rhino heaps before, and it has been great.
I have started to realise that the 'all in' solution is probably the best, i.e. Rhino will force the restructure to use full Inversion of Control which will force good design decisions.
Regardless of which mocking framework I use I would be comfortable that I myself could make good design decisions as I have done heaps of work like this before, but others working on the code have not done unit testing before, so the scenario that forces them to use IoC is better.