The many approaches to Entity Framework

Re:The many approaches to Entity Framework by highace on Monday March 04, 2013 @07:57AM (#5317946)

I used to go down the repository/unit of work route but I found that just adds loads of unnecessary abstraction and complication. Now I simply expose the data context through an interface and inject that into my controllers. For testing I use a fake data context.

[ Parent | on HN ]

Re:The many approaches to Entity Framework by jchannon on Monday March 04, 2013 @08:02AM (#5317955)

Unfortunately EF doesn't provide a interface. Unlikely I know but what if you swapped your ORM, wouldn't that mean a lot of refactoring?

[ Parent | on HN ]

Re:The many approaches to Entity Framework by PommeDeTerre on Monday March 04, 2013 @08:17AM (#5318012)

There's going to be a lot of refactoring either way, whether there are custom abstraction layers in place, and whether there aren't.

The abstraction layers that were originally intended to ease a transition between ORMs or DBs often end up making such a transition far more difficult. They just end up being another huge amount of code that needs some type of refactoring.

[ Parent | on HN ]

Re:The many approaches to Entity Framework by dodyg on Monday March 04, 2013 @10:29AM (#5318621)

ORM swapping is YAGNI.

[ Parent | on HN ]

Re:The many approaches to Entity Framework by joshka on Monday March 04, 2013 @08:08AM (#5317978)

IDbSet<T> is enough. If you swap your ORM, you're swapping mindset more than just methods, unless you're mapping ORM entities to POCOs in your repository object.

[ Parent | on HN ]