Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Is ADO.NET Entity Framework Enterprise Ready?
Posted by Jonathan Allen on May 22, 2008 02:55 PM
The ADO.NET Entity Framework relies heavily on visual modeling tools. But are these tools really appropriate for large scale development?
In a piece titled Visual Designers Don’t Scale, Scott Allen talks about the problems of Visual Scalability. Essentially this problem comes down to the sheer size of the diagrams. When you have to deal with hundreds or thousands of tables,
They are difficult to navigate, and impossible to search. The layout algorithms don't function well on these large datasets, and number of mouse clicks required to make simple changes is astronomical. The best you can do is jump into the gnarly XML that hides behind the visual representation.
He goes on to predict a change back to textual representations of data models.
Ayende Rahien also sees problems with source control. In reviewing the source control support for the visual designer he discovered that even minor changes in the position of a single screen element could cause merge conflicts. Now imagine the mess if someone were to mistakenly hit the auto-layout button and all the table/entities were moved.
RelatedVendorContent
Effective Management of Static Analysis Vulnerabilities and Defects
Ensuring Code Quality in Multi-threaded Applications
NEW: ANTS Memory Profiler 5 just released!
Related Sponsor
Red Gate Software makes ingeniously simple tools for over 500,000 SQL Server and .NET professionals.
Depends...
by
Francois Ward
Posted
May 22, 2008 3:07 PM
Ruurd Boeke provides support for Plain Old C# Objects
by
Gael Fraiteur
Posted
May 22, 2008 11:18 PM
-
Visual representatons of data models work fine when either:
A) they can be split in many sub representations:
or
B) they're disposed in a treeview type fashion.
A is like Sql Server database diagrams, B is like LLBLGEN Pro or the CTP of the XSD designer of VS2008.
It works fine, it just has to be engineered properly. That said, while most enterprise apps you hear about have thousand of tables, bazillion lines of code, etc (I've worked on many), most enterprise apps are much, MUCH smaller, including advanced ERP systems used by Fortune 20 companies. For that, EF would work just fine.
Besides, I don't see why people see the Ado.net EF as different from everything else built in the .NET Framework. Its all entry level stuff that fits most requirements, but not the top ones.
Need caching? ASP.NET's caching is there. Need extreme caching? Get NCache.
Need to make an ASP.NET app? Use the boxed controls. Need something with fancy features? Infragistic, Telerik, ComponentArt, whatever...
Need an ORM, use Linq to SQL. Need more? Entity Framework. Need a specialized solution that will scale like nuts, use LLBLGEN Pro, some other tool, CodeSmith, build your own, whatever.
The thing is, different "enterprise apps" will be ok with different parts of the entry level framework, so just choose and pick. For here, the EF will do just fine. Last job I had? No way! Amusingly enough, my current company is the larger one...
-
It's worth noting that Ruurd Boeke contributed a solution that turns Plain Old C# Objects (POCO) into EF-aware objects. The project is called PostSharp4EF and is free and open source. It relies on PostSharp for post-compilation assembly transformation (the way many other ORM do).
2 comments
Watch Thread Reply