What do entity frameworks try to achieve?

[Author #1]

I am sure a lot of people in the c# community have used some kind of
entity framework such as NHibernate, Castle, .netTiers, to name a
few. It's my feeling that these frameworks try to move traditional
database tasks into our modern object-oriented programming languages
such as C# and Java. Is this correct?

Actually, I've also used some of such frameworks, such as .netTiers
and SubSonic. I think that such framework can be very helpful for
simple database tasks like plain and simple CRUD operations. But, I
also quite often find that it is very hard to do complicated database
operations with such entity frameworks. For example, if we have quite
a few things to do before or after plain CRUD operations, such
frameworks will be rather cumbersome. So, in a project of mine, I
ended up using SubSonic as a wrapper for my stored procedures I wrote
in my SQL Server.

Here is my quick question: What do entity frameworks try to achieve?
Are they sufficient for complicated database tasks?

 

[Arne Vajhøj]

I am sure a lot of people in the c# community have used some kind of
entity framework such as NHibernate, Castle, .netTiers, to name a
few. It's my feeling that these frameworks try to move traditional
database tasks into our modern object-oriented programming languages
such as C# and Java. Is this correct?

Actually, I've also used some of such frameworks, such as .netTiers
and SubSonic. I think that such framework can be very helpful for
simple database tasks like plain and simple CRUD operations. But, I
also quite often find that it is very hard to do complicated database
operations with such entity frameworks. For example, if we have quite
a few things to do before or after plain CRUD operations, such
frameworks will be rather cumbersome. So, in a project of mine, I
ended up using SubSonic as a wrapper for my stored procedures I wrote
in my SQL Server.

Here is my quick question: What do entity frameworks try to achieve?
Are they sufficient for complicated database tasks?

I have not used EF much, but I will assume that it is trying to
achieve the same as other ORM and that it is as good as the
better other ORM's.

But you should note that ORM's are not a good choice for
all database usage. And EF is not a good choice for those
more than any other ORM.

As in so many other contexts: pick the right tool for the
job.

Arne

 

[Author #1]

I have not used EF much, but I will assume that it is trying to
achieve the same as other ORM and that it is as good as the
better other ORM's.

But you should note that ORM's are not a good choice for
all database usage. And EF is not a good choice for those
more than any other ORM.

As in so many other contexts: pick the right tool for the
job.

Arne

Thanks. Do you agree that EFs are helpful in doing only simple CRUD
operations and for complicated database tasks, they quickly get out of
hand?

 

[Arne Vajhøj]

Thanks. Do you agree that EFs are helpful in doing only simple CRUD
operations and for complicated database tasks, they quickly get out of
hand?

As I said then I am not that experienced with EF, but for ORM in
general, then:
- ORM is good when objects make sense which is usually the
case for OLTP
- ORM is not good when objects does not make sense, which
is usually not the case for DWH

The SQL needed for OLTP is usually rather simple compared
to the SQL needed for DWH.

(and ORM is obvious not good for DBA DDL tasks)

So I think that what you are observing is not so much
a case of limits in implementation but more a case of
limited by nature of what it was designed for.

Arne