0

I'm developing software (libraries, Web pages, Web API, desktop applications, etc.) using C#, .NET Framework 4.0 and Entity Framework Code First.

To develop this software I'm using Dependency Injection with Ninject, and patterns Generic Repository and Unit of Work.

This is the first time I use those patterns and I thought that using Ninject I will solve the problem of coupling.

Now, I have improved my database and I have changed model. The database has the same functionality that the previous one but with less tables and less columns. To do that I have changed my E.F.'s POCO classes and here comes all of my problems. These problems come because I'm using these POCO classes inside my business logic and if I change them I have to change business logic.

I thought that using Dependency Injection I will isolate data layer from business layer, but it doesn't. If changing my data layer I have to change business layer I'm coupling both.

This always happens or have I done something wrong?

VansFannel
  • 45,055
  • 107
  • 359
  • 626
  • _"...and here comes all of my problems"_ - what problems are you encountering? Can you provide specific examples? – Metro Smurf Feb 13 '16 at 18:48
  • These problems come because I'm using these POCO classes inside my business logic and if I change them I have to change business logic. – VansFannel Feb 14 '16 at 20:07

1 Answers1

0

Dependency injection allows you to substitute in alternative implementations of a contract, usually via an interface. That contract is made up of types and methods, so if either changes you have a new contract. Your POCOs are part of this so out have to expect changing them will generate rework.

If you separate out model classes outside of entity framework and use them you'll get better separation but more type casts.

kidshaw
  • 3,423
  • 2
  • 16
  • 28
  • I agree with you up to a point. That point is the most common mistake when using EF. The point of EF is to map your Domain Objects to your Database. Entity Framework should be the point of flexibility to join the inflexible database with the idealized Domain Model. Ergo, reworking EF is precisely the point, to isolate the changes of your Domain Objects from the Database. – Aron Feb 13 '16 at 18:50
  • If you are using EF to define your model classes you've still got changing definitions when you remodel. But the issue is around Injection? Whilst you can use these objects in your interface contracts, you'll never escape rework if the object definitions change. You could perhaps interface the model classes with base functionality, but the level of flexibility you want, any solution is just going to move that burden around. I'd be interested to see what others have to say, sorry I can't think of another solution. – kidshaw Feb 13 '16 at 20:10
  • If you use EF to define you model classes then you aren't using POCOs. – Aron Feb 13 '16 at 20:36
  • Be they POCO or not, using EF is making the developers life easier - that will always add limitation. – kidshaw Feb 14 '16 at 08:11