C# Object Oriented Programming

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!
 
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
 
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.
 
Last edited:
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.
Click to expand...

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
 
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.
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top Bottom