C# Object Oriented Programming

Trucamo · 20 Jul 2014 at 20:39

Entity Framework is an implementation of an ORM (Object-relational mapping), other implementations include NHibernate, Linq-to-SQL, Dapper etc.

They sure do make life a lot easier!

Blackvault · 21 Jul 2014 at 10:02

Just a quick update on Entity Framework. I have implemented it for my user object within my application and it really cuts down the code. Shame I'd already written my Insert and Update SQL statements.

Blackvault

Gornall · 21 Jul 2014 at 11:04

While not particularly relevant for your project I admit, business logic changes. I'd much rather be able to issue that 'fix' at the SQL Server side (which fixes it 'globally' essentially) than have to adjust and recompile/redistribute the software. I say this as a SQL Developer, as such a little biased I'm sure. But it's my trade, and generally I can provide a more robust data solution than a software dev with some SQL knowledge.

EF is great, and will probably kill off L2S.

My general rule of thumb:

Big Data sets/Bulk operations - Procs
Single Entity operations - EF.

Blackvault · 21 Jul 2014 at 13:37

Gornall said:
While not particularly relevant for your project I admit, business logic changes. I'd much rather be able to issue that 'fix' at the SQL Server side (which fixes it 'globally' essentially) than have to adjust and recompile/redistribute the software. I say this as a SQL Developer, as such a little biased I'm sure. But it's my trade, and generally I can provide a more robust data solution than a software dev with some SQL knowledge.

EF is great, and will probably kill off L2S.

My general rule of thumb:

Big Data sets/Bulk operations - Procs
Single Entity operations - EF.

Thanks for your thoughts on the matter. I can appreciate that EF isn't the last word in coding

Its a relative basic application and will only really require CRUD operations for my user profile.

Blackvault

GravyMonster · 21 Jul 2014 at 17:05

Gornall said:
Big Data sets/Bulk operations - Procs
Single Entity operations - EF.

Completely agree with this. EFs advantage is as a RAD tool. Using it with large datasets in an Enterprise scale application is asking for your P45.

Haircut · 21 Jul 2014 at 19:00

Gornall said:
While not particularly relevant for your project I admit, business logic changes. I'd much rather be able to issue that 'fix' at the SQL Server side (which fixes it 'globally' essentially) than have to adjust and recompile/redistribute the software. I say this as a SQL Developer, as such a little biased I'm sure. But it's my trade, and generally I can provide a more robust data solution than a software dev with some SQL knowledge.

EF is great, and will probably kill off L2S.

My general rule of thumb:

Big Data sets/Bulk operations - Procs
Single Entity operations - EF.

Generally for most LOB applications I'd expect the data access code to exist on a server, so should be just as easy as modifying a stored proc.

Yes, you have to recompile the server code, but if that's any more complicated/requires more process than changing a stored proc then you're probably doing something wrong IMO.

That said I tend to agree with your general categorisation of uses.
ORM tools certainly aren't a panacea and they are definitely a leaky abstraction. If you don't know SQL well then you'll probably come unstuck sooner or later trying to use an ORM tool.
Plus you have issues like n+1 selects to contend with if you're not careful.