entity framework, mutual enough, worth effort?

  • Thread starter Thread starter Ryan Liu
  • Start date Start date
R

Ryan Liu

Hi,

I heard Microsoft suggest EF as data access method, and no more development
for linq to sql.

So I change my current project, which was started not too long time ago, to
use EF.

Then later I run into this and other kind of problems, like no support for
enum, uint, and seems has problem to refresh itself from Visual Studio 2008
after db schema/stored proc changed. And method signature auto-generated is
wrong for stored proc , for example , I have a parameter name referenceId,
it is a guid/varchar, but the auto-generated method signature says it is
int.

My question is, actually how many companies out there are really use EF for
enterprise application? What is trend for EF/data access? Is EF mutual
enough? We know, not everything Microsoft pushes is success, for example
Vista. I don't want to develop something, later will be abandoned.

Actually I'd rather use my old way to implement dataacess layer, it will be
much faster for me since I am familar with it. The argue that application
developer should not concern about database is not that valid for me. I am
quite familar with sql, but not entity sql, and I need know db schema
anyway. And most function I still implement it in stored proc anyway.

Thanks a lot!
Ryan
 
I heard Microsoft suggest EF as data access method, and no more development
for linq to sql.
Click to expand...

Note that this doesn't mean that LINQ to SQL is unsupported, or that
there won't be new additions. It's just that you probably won't see
any major stuff. But if LINQ to SQL, as it is today, works for you,
then by all means use it.
So I change my current project, which was started not too long time ago, to
use EF.

Then later I run into this and other kind of problems, like no support for
enum, uint, and seems has problem to refresh itself  from Visual Studio2008
after db schema/stored proc changed.  And method signature auto-generated is
wrong for stored proc , for example , I have a parameter name referenceId,
it is a guid/varchar, but the auto-generated method signature says it is
int.

My question is, actually how many companies out there are really use EF for
enterprise application? What is trend for EF/data access?  Is EF mutual
enough? We know, not everything Microsoft pushes is success, for example
Vista.  I don't want to develop something, later will be abandoned.
Click to expand...

As many other technologies, EF has to go through a maturity stage.
Right now it's at v1. Look behind and remember what WPF was like back
then; and it still has its rough edges. If you think EF is not worth
your trouble, then chances are that you're right. However, keep in
mind that .NET 4.0 is coming, with EF v2 - and it fixes a _lot_ of
common grievances such as the ones you mention.
Actually I'd rather use my old way to implement dataacess layer, it will be
much faster for me since I am familar with it. The argue that application
developer should not concern about database is not that valid for me. I am
quite familar with sql, but not entity sql, and I need know db schema
anyway.  And most function I still implement it in stored proc anyway.
Click to expand...

If a tried and proven method works well for you, then I'd say stick to
it. There's no point in using the latest and greatest just for the
sake of it - if you feel you aren't actually better off, then don't
bother.

On a side note, remember that there are third-party .NET ORMs, too.
NHibernate is a pretty good free one (but last I checked, no complete
LINQ support); LLBLGen is a commercial one and rather idiosyncratic
(IMO), but handles LINQ excellently. And there are more if you look
around.
 
Ryan Liu said:
Hi,

I heard Microsoft suggest EF as data access method, and no more
development for linq to sql.

So I change my current project, which was started not too long time ago,
to use EF.

Then later I run into this and other kind of problems, like no support for
enum, uint, and seems has problem to refresh itself from Visual Studio
2008 after db schema/stored proc changed. And method signature
auto-generated is wrong for stored proc , for example , I have a parameter
name referenceId, it is a guid/varchar, but the auto-generated method
signature says it is int.

My question is, actually how many companies out there are really use EF
for enterprise application? What is trend for EF/data access? Is EF
mutual enough? We know, not everything Microsoft pushes is success, for
example Vista. I don't want to develop something, later will be
abandoned.

Actually I'd rather use my old way to implement dataacess layer, it will
be much faster for me since I am familar with it. The argue that
application developer should not concern about database is not that valid
for me. I am quite familar with sql, but not entity sql, and I need know
db schema anyway. And most function I still implement it in stored proc
anyway.
Click to expand...

The best practice in using an ORM solution is not to use sprocs, as it
defeats the purpose of an ORM and the virtual database.

Yes, I am using EF in a production environment with ADO.NET Data Service and
WCF Web service. EF IDE has a couple small issues with the IDE. But other
than that, I have no regrets in using EF.



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4035 (20090425) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
Back
Top