5

I have a few questions regarding decoupling my domain layer and data layer in an MVC3 web application using entity framework as the data access layer.

As it stands right now my controllers are completely dependant on the EF classes and after spending most of the day reading up on dependency injection I am trying to decouple them.

The first question I have is - do I need to effectively duplicate all of the EF classes into my business layer? I obviously cant use the EF classes any more so it seems to me that I need to create a duplicate of every table class in use to get this working. Is this right? So for example if I have 50 EF classes representing 50 tables in my DB, do I need to create 50 new classes in my business layer? -> and then maintain them indefinitely? This sounds like a lot of work.

Secondly, am i correct in assuming that the dependancy gets flipped around and instead of the business layer being dependant on the data layer, the data layer ends up becoming dependant on the business layer?

Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
Grant
  • 11,138
  • 32
  • 94
  • 140
  • I create seperate viewmodels for use by my views, and populate these from my EF Models. – DavidB Mar 20 '13 at 09:30
  • I think you'll find theres a trend these days to use the EF models in your controller (even though you are coupling to EF), as long as you dont return these models to the views its usually not a big issue, unless you plant to change persistance framework, which these days theres becoming less and less reason to – Daniel Powell Mar 20 '13 at 09:33

2 Answers2

3

For the duplication of your entities... it depends the version of EF and the approach you use.

If you use POCO entities, then your model is not related to EF as your entities don't inherit from EntityObject. So you wouldn't have to duplicate your entities. At runtime, thanks to proxy entities, EF will generate dynamic types that inherit from your POCO and add all the EF plumbing for lazy loading...etc.

In any case, do note that because of ASP.Net MVC, you'll always end up by duplicating some model classes into what's called view models, so you can strongly type your views.

Secondly, am i correct in assuming that the dependancy gets flipped around and instead of the business layer being dependant on the data layer, the data layer ends up becoming dependant on the business layer?

No, the data layer shouldn't be aware of the business layer.

ken2k
  • 48,145
  • 10
  • 116
  • 176
  • Forgive the question but how do i know if i am using POCO entities? as i am coming accross from LINQ2SQL its all pretty new. what i can tell you is that i am creating the EF classes using DB first and the designer does the rest - just like in LINQ2SQL. And if the DAL is not aware of the BL, what 'Types' is the DAL returning? datasets? i was hoping to return proper classes representing my data.. – Grant Mar 20 '13 at 09:36
  • @Grant What you could do is see if your entities inherit or implement any EF-related class/interface (EntityObject) – ken2k Mar 20 '13 at 09:38
  • i cant see any reference to EntityObject. i have my model.context.tt and then the designer. the diagram and then model.tt with a bunch of classes underneath representing all of my tables. does this mean i am using POCO entities? – Grant Mar 20 '13 at 09:42
  • @Grant If you have T4 templates (*.tt files) and if your entities doesn't inherit from any EF-related class, then yes. – ken2k Mar 20 '13 at 09:57
1

You can put your model classes in a separate assembly to your context.

If you do that, your data layer, business layer and website can all reference the model assembly, but you can isolate the other dependencies - e.g. the website assembly won't have a direct reference to the data layer, which means it doesn't have to reference EF either.

If you're using code first, this is simple.

If you're using database first, then remove the reference to your model .tt file from your context assembly. Don't delete or move it, but add a link to it in your new model assembly.

To add a link, right-click your project in solution explorer and choose "Add -> Existing Item". You then get a file chooser dialog. The "Add" button on that dialog has a drop down where you can choose to "Add as link".

Nick Butler
  • 24,045
  • 4
  • 49
  • 70
  • how exactly do i remove the reference to my model.tt file? and are you suggesting that these EF classes are my domain model classes and i should use them as such? – Grant Mar 20 '13 at 09:48
  • To remove the reference to your `model.tt` file, right-click it in solution explorer and choose "Exclude From Project" – Nick Butler Mar 20 '13 at 09:50
  • And, yes - because POCO classes are essentially just data buckets, it is becoming more usual to use them to move data between all your assemblies. This comes with the benefit that the navigation properties - the schema of your database - is encoded in them, so you can create things like `Where` and `OrderBy` clauses in your website assembly, without having a reference to EF or even your `DbContext` – Nick Butler Mar 20 '13 at 09:53
  • thanks Nicholas. but there is no option under the model.tt file to exclude or remove from project.. ? - i can only exclude the parent model.context.tt.. not model.tt – Grant Mar 20 '13 at 09:59
  • There should be - are you sure you're viewing the "Solution Explorer" tab? – Nick Butler Mar 20 '13 at 10:01
  • yeah i sure am. the Model1.tt file is a child of Model1.Context.tt. the parent i can exclude but i am not able to exclude any of the children including the Model1.tt item. VS2012, Update 1 – Grant Mar 20 '13 at 10:02
  • I really need to see your solution to help more - you can contact me via my company website in my profile. – Nick Butler Mar 20 '13 at 10:32
  • You also need to be not debugging to remove the files – Daniel Powell Mar 20 '13 at 11:07