SubSonic: SonicCast 6 - LINQ, LinqToSql, and SubSonic
Thursday, August 02, 2007 -
SonicCast #6 is ready to go, and this one's all about LinqToSql - Microsoft's new ORM toolset. I take a look at it from an architectural point of view, and also discuss what it means for SubSonic.
Keep Readin...
As with all ORM tools - there are potential drawbacks and possible quagmires. Microsoft doesn't push any single architectural approach on anyone (as opposed to RoR, which has pretty one way only), that can lead to interesting problems for software architects (and group managers wishing to decrease the code review cycle time). I for one still struggle with the concept of the Object Data Source and why people like to use it, and the SqlDataSource makes me cringe and shudder.
I've found that this same "flexibility" is present in LINQ (as it is in SubSonic) - but will LinqToSql allow me to wrap some decent architecture around it? Will it be possible to keep eager devs from putting LINQ queries in code-behind? Watch and see...
A Favor - I Need Your Opinion
Finally - I want to hear from you RE your thoughts on where SubSonic should go with respect to .NET 3.5, LINQ, and LinqToSql. This is a community project and (as Phil Haack puts it) I'm the benevolent dictator but I don't feel right making any decisions on this stuff without listening to the community, gaining perspectives, and gathering ideas.
There is a LOT of overlap here (in fact LinqToSql pretty much does 90% and then some of what SubSonic does), but the focus of SubSonic has always been getting you home in time to watch Survivor with your family. Can we add this sort of flavah to .NET 3.5 and LINQ?
Sound off yo!
my suggestion, off the cuff, is to become the Rails to microsoft's Ruby (.net)...focus on being "SubSonic is a toolset that helps a website build itself." and if that means linq/linqtosql becomes the dataservice tier, then so be it.
again...i need to think about it more myself, but thats' my first impression.
I'm watching the cast right now; so I guess I'm live-commenting.
My first reaction is "codegen good, gui based tools bad".
note: i need to read/watch scottgu's linq posts.
I'm wondering about genning controllers/models, templates, MVC/MVP..
Yeah, its databroker like..
please say that Linq is not fetching all products before filtering on category. I have to guess so base on your performance comments.
I'm unsure about SubSonic/others in light of Linq2Sql, considering its only Beta so far. SubSonic and others at least support good design, and I don't like that Linq makes it so easy to write messy code like the first databind example.
Here's something.. would linq2sql allow replacing sql statements with sprocs? I see that as a huge advantage for SubSonic/ActiveRecord/nHibernate because sometimes sprocs make more sense/better perf.
i guess I better code checkout scottgu's posts before I start a new project.
The entity framework appears to offer a ton of features at the cost of complexity. It seems to fall into a category similar to NHibernate. LINQ-to-SQL allows developers to throw around queries in code-behinds and where-ever else with wild abandon, just as they would with SQL strings and SqlCommand objects. I would like to see SubSonic (and LINQ-to-SubSonic) fit somewhere in the middle.
So the question seems to be, because LINQ-to-SQL provides much of SubSonic's existing functionality, should SubSonic shift gears a bit and begin encouring its users to adhere to a more structured data modeling approach? We WILL see LINQ queries jammed into code-behinds everywhere of course, so could SubSonic continue to offer simplicity, while at the same time allowing developers to more easily embrace better architecture patterns?
I guess what I'm getting at is this: SubSonic has made structured data access accessible to many developers through simplicity and ease of use, where MS previously did not. Now, with MS taking a step forward to provide higher quality data access functionality, so too shouldn't SubSonic take a step forward and make quality architecture accessible, just as it did with data access?
Like I said, I'm no expert. I only wish my employer would adopt ANY ORM... :(
~"Some time at the end of 2007, all Morts were united. He marveled at his own magnificence as he gave birth to LinqToSql."
[if you recognize that, you're a bigger geek than me. I had to look up the quote to paraphrase it right.]
My concern with L2S, and ORM in general, is that it encourages poor code and design.. unless tools like SubSonic are used to keep things sane.
Good feedback... keep it comin...
Code Generation
Winner: SubSonic
Reason: Flexible, template driven, and very solid. Dead easy to refresh schema changes. SqlMetal has a couple of very annoying bugs. I think the GUI-based dbml thing is kinda crap.
Language Integration
Winner: Linq
Reason: The data-shaping capabilities and the sproc result interfaces (IResult, etc) are just mad powerful.
Community Support
Winner: SubSonic
Data Updating (as observed in the 'cast)
Winner: Tie
Reason: Calling Save() a la SubSonic on a mapped object just feels a lot more natural. The implicit transaction wrapping by SubmitChanges is a very nice feature in Linq.
And last, and far from least, we have the source code for SubSonic. When dealing with the huge layers of abstraction OR mappers provide, being able to get a look under the hood is utterly invaluable. And this won't be changing with RTM Linq.
As of Beta 2, I'll be using about 75% SubSonic and 25% Linq. I don't (and won't until the next patch or release) feel comfortable yet doing anything but reading data with Linq to SQL. I'll be using SubSonic for Inserts/Updates.
My 2 cents. Thanks again for a killer app.
The biggest problem with LINQ to me is how the heck do you surface dynamic data properly out of the data layer - LINQ with its anonymous types that don't stay strongly typed out of the business layer kind of puts a big wrench in the strategy and flexibility.
I agree with some assesments above that Linq to SQL sounds like fun until you run into something beyond the simple mapping it provides. Then you start running into trouble because the generator is not that flexible.
I'd think for SubSonic (and my own generator as well) it might be interesting to generate the SQL Entities instead of letting SQL Metal do it. It's all just classes, but if you build off your own base classes there's probably lots of opportunity to enhance the base context behavior and certainly provide more flexibility for entity generation. For example, generating DataContracts and INotifyChanged etc.
I'll be down this path again over the next few weeks so I'll be watching were you're headed too.
I also appreciated you talking a bit about how you organize your code, as I am relatively new to ASP.NET and still trying to work out what the best folder / class structure to use when starting new projects.
Both seem to have a lot of overlap, so which do you choose? I certainly don't want to see SubSonic die off, it has really made my daily work a lot easier. I'm getting ready to show it off to about 15 of my co-workers.
Syntactically, SS wins big time. Do you really have to instantiate that Context object each and every time in L2S? Yuck!
(ofcourse, I can't say I like having the using SharedDBConnectionScope all over the place either ;-) )
My opinion is to keep on trucking. I'm really looking forward to seeing the new REST stuff in action along with the new query engine.
How about supporting some WPF style collections in the future?
I don't have any Architectural recommendations for you. I believe you, Eric and everyone else have done an outstanding job in this area and all I can offer is encouragement and support to "Keep up the great work!".
My recommendations, however, are more philosophical, and that is to "Stay the course". To me, SubSonic is more than just another pretty ORM. Honestly, I've been researching ORM's for a long time and although there are some really elegant and well thought out products out there, it was SubSonic's ease of use, straightforwardness, easy learning curve, community support, and development response that won me over.
SubSonic fills a gap for us .Net developers and even with new features coming out in the 3.5 framework gaps are still going to exist. And SubSonic will be there to "Save the day!".
So as time draws near to the release of the .Net 3.5 framework and even beyond, I'm sure someone in the SubSonic community will recommend how SubSonic can take advantage of and improve the new features.
In the meantime, keep up the great work!
I think your cretiques of LINQ to SQL are valid. Things that would be cool in SubSonic would be:
LINQ/Lambda syntax for creating the Query object.
Partial Methods for extending methods in the generated Partial classes (OnBeforeCreate, OnAfterCreate, etc)
Things that will keep me from Linq to SQL:
No many-to-many support (not in beta2 anyway)
Support for multiple databases.
No apparent way to modify the generated code at generation time.
Thanks for you informative screencasts.
Toward the end, you mentioned that you hadn't gotten the DBService Update to work. You may have already found this, but I think what you want is the "Attach" method on the DataContext. Something like:
public static void Update(Northwind.Product p)
{
Northwind.NorthwindDataContext db = new Northwind.NorthwindDataContext();
db.Products.Attach(p);
db.SubmitChanges();
}
Compared to SubSon...