New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Is ADO.NET Entity Framework Enterprise Ready?
Posted by Jonathan Allen on May 22, 2008
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
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
A Guide to Branching and Merging Patterns
SCM best practices for multiple processes, releases & distributed teams
Depends...
by
Francois Ward
Posted
Ruurd Boeke provides support for Plain Old C# Objects
by
Gael Fraiteur
Posted
-
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