The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Jonathan Allen on Jul 24, 2008
More and more, LINQ to SQL is being seen as a temporary solution. With the impending release of ADO.NET Entity Framework, a lot of people are worried that development on LINQ to SQL will fall by the wayside. With Microsoft's long history of developing and discarding database access technologies, these concerns are not without merit.
Further compounding the issue is that LINQ to SQL has been transferred to the SQL Data Programmability team, the very same group working on ADO.NET Entity Framework. With their own project filling a similar role, it is hard to see them wanting to devote a lot of time to the adopted project.
So this raises the question, "Should LINQ to SQL Go Open Source?" Leon Bambrick asks that question and provides some analysis. One of the biggest concerns he raises is the liability issue, wherein Microsoft may be reluctant to ship something with the framework that has had external contributions. On the other hand, it might be what's needed to push through community-driven features such as mockability and multiple providers.
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Fair Trade Software Licensing - A Guide to Neo4j Licensing Options
LINQ to SQL is for small to "less small" (not quite medium =P) solutions... half a notch up from Typed Datasets. LINQ to Entity doesn't replace that, and its with that mindset that LINQ to SQL was developed (also as an introduction to other ORMs, to put the idea on the map).
LINQ to SQL serves its purpose pretty well seen from that angle, so its probably fine.
It would be a shame if LINQ to SQL proves to be only a temporary solution; now that it has been officially released I think Microsoft has a duty to provide a decent lifecycle for this product.
My biggest objections to LINQ to SQL are following:
1. LINQ to SQL works only with Microsoft SQL Server
2. LINQ to SQL is that it is no 100% POCO. Framework forces you to use System.Data.Linq.EntitySet type on "many" side of one-to-many relationship and EntityRef on the "one" side of one-to-many relationship.
3. Single table inheritance
These are not the only ones, but you have to give them some slack since this is the first version of the product.
Some interesting background on LINQ to SQL origins:
The LINQ to SQL was never even supposed to exist
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
2 comments
Watch Thread Reply