4

I've just used IoC on a very small project with only one object i needed to test. I'm now starting to implement it into a larger existing project and I'm unsure of something.

Say i have two business objects Student and Teacher both have constructor injection for an interface called IUnitOfWork which has concrete instantiations of SQLUnitOfWork or InMemoryUnitOfWork.

So if i'm using this library I can use IoC to construct my object no worries, but what happens when I want to use one inside the other? So say I was lazy loading a property Student.Teacher and need to get a new Teacher object, how do I do it?

Something doesn't seem right about using an IoC container to achieve this, but neither does having concrete objects. Using IoC on every single object used seems excessive.

g.foley
  • 2,152
  • 3
  • 19
  • 27

2 Answers2

1

I generally avoid using IoC in the domain layer - you want to try and access the kernel only in the application layer (where, yes, you may access the kernel quite a lot).

For my projects, all my business objects are generally POCOs with few dependencies on anything other than framework stuff.

The service layer tends to have lots of dependencies, but doesn't access the kernel directly very often.

Whether you can do this is going to depend on your choice of ORM etc., and of course the existing architecture of the project.

If your business objects have dependencies that need to be resolved, then you are either going to need to use the kernel to resolve them, or refactor your project to remove the dependencies.

cbp
  • 25,252
  • 29
  • 125
  • 205
  • What do you mean by kernel? Also I don't understand how I can design a domain model which doesn't reference other objects in the model, is there something I should read up on to help me understand this? – g.foley Mar 30 '11 at 06:13
  • @g.foley: Kernel is the term some IoC frameworks use for their container; the object that allows the creation and returning of new instances. – Steven Mar 30 '11 at 07:18
  • 'Kernel' is just another word for the IoC container... sorry, I use NInject and for some reason they call it a kernel rather than a container. Yes, there is lots to read but where you start is going to depend on your platform, ORM etc. – cbp Mar 30 '11 at 07:19
  • I'm still stuck on this idea of designing a domain model where objects aren't referencing each other. I'm using .net, castle windsor and a proprietary ORMish code generator. Back to my original example, student would have a teacher object how do i construct that teacher object from within student? – g.foley Mar 30 '11 at 23:28
  • You can reference the teacher class from your student class. That is fine. Generally though, you wouldn't often be constructing new teacher object from within the student object. It would be up to your ORM, service, or application layers to construct new student and teacher objects. That being said, if your domain entities are simple POCOs then you should be able to easily construct them without using the Kernel, as they should have no dependencies that require the Kernel. This is a big topic - very difficult to explain in a 300 character comment! – cbp Jun 16 '11 at 04:34
0

Instead of having dependencies in your Student and Teacher classes (UnitOfWork), have a service layer with dependencies that references the Student and Teacher classes.

This way your entity classes can be POCO's and easily mocked in tests etc.

Marcus
  • 1,866
  • 1
  • 20
  • 33