Real World Apps in Days not Weeks
I've given a number of presentations on ADO.NET Data Services (formerly codenamed: "Astoria") and I'm still convinced that if what it does fits your scenario, you can get a metric ass-load of work done in a short period of time.
Here's a real world example. A buddy of mine gives me a call and says he's been asked to do an application for a large clothing manufacturer. It'll run on the client machine and need to retrieve Apparel details over the web. He tells me he was thinking of using Web Services, maybe ASMX Web Services.
I asked him if it was primarily going to be CRUD (Create, Read, Update, Delete) type operations, nothing too fancy. He said yes, there'd be some sorting and filtering, but that'd be it. Should I write an HttpHandler and just return an Xml document? Some format I'll make up? he says. (Sound familiar? Kind of 2004, eh?)
Does it need an administrative console?, I ask. He says that'd be nice, but it wasn't spec'ed out. He figured this would be pretty low rent. The client even suggested (gasp) that they could just maintain a local XML file. After I threw up in my mouth a little, I made a few suggestions. ;)
Remembering that the goal here is for the solution to be simple, clean, and robust. It's also to under-promise to the client, but over-deliver. It's also worth noting my friend did a fixed bid for the work, so he just wanted to get it done.
We busted out the napkins and pens over lunch and scribbled some ideas, lovingly reproduced above in Paint.NET.
In about an hour, he described the Domain Model and we created a database using LINQ to SQL. We filled it with temp data and created a new Visual Studio Solution. We added a WPF app and an ASP.NET Website.
To the website we put in our LINQ to SQL .dbml so we had our Data Context. We added a new ADO.NET Data Service and hooked it up to the Data Context. I then showed him how he could query the entity model with HTTP calls. Then we moved based the browser-based examples and added a Service Reference to our WPF app and I showed him "LINQ to REST."
Next, we created a ASP.NET Dynamic Data website, but ended up combining it with our previous site, so we had a single ASP.NET website that was both a Dynamic Data site that also included an ADO.NET Data Service. The out of the box ASP.NET DD experience gave him a complete admin site that he'll wrap in either Windows Auth or ASP.NET Forms Auth - both things he already knows how to do as an ASP.NET developer.
We were able to get a nice working skeleton for his application in an hour. He used the ObjectDataProvider in WPF to bind the entities returned from ADO.NET Data Service to lists and combos in his client app. He got a free admin site that he can skin with CSS or change the markup to taste.
He's spent the last few weeks, on and off, going back and forth with the designer who wants the WPF app to look this way or that way, and he's changed the data model a few times, but the work in that first hour over lunch set the tone for his whole project.
Hopefully I'll get his client to agree to let me use the app as a case study or something and I'll be able to give you, Dear Reader, a LOT more detail about that first hour.
A reminder, also. All this stuff, everything we used ships today in .NET 3.5 SP1. We didn't use anything beta.
For now, though, here's some links:
- Consuming Ado.Net Data Services from WPF
- Pablo Castro: Astoria Data Services
- LINQ to REST example
- ADO.NET Data Services Futures blog post
- ADO.NET Data Services "Offline" Futures
- Beth Massi on ADO.NET Data Services
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Michael C. Neel
http://msdn.microsoft.com/en-us/magazine/cc794279.aspx
LINQ to REST looks neat!
Here's my case...we are not building a line of business application...we're re-building a VB6 "product" application into .NET. Our early work on that was built-out in using L2SQL. Development of that was fast and perfect for our needs. Then we read about the developments, or lack thereof (heh), surrounding it, and we're stuck. EF is something we've been experimenting with, but for our needs L2SQL was just a very nice fit. But we can't build out a product that needs to last (and sell) based on a core technology that's going nowhere.
Sorry for the rant, but it needs to be said. That said, great post and thanks!
FYI -
For folks using ADO.NET Data Services with Linq to Sql and/ or Sub Sonic I have written a couple of reference implementations of IUpdateable that are available on Code Gallery:
http://code.msdn.microsoft.com/IUpdateableLinqToSql
http://code.msdn.microsoft.com/SubSonicForADONETDS
(Note - the SubSonic implementation needs to be updated to the latest beta of SubSonic. Any volunteers?)
See the below post for the gory details on why this is needed - but the bottom line is you will need to implement IUpdateable if you want to use other DALs other then Entity Framework and you want full CUD (Create, Update, Delete) support with the Astoria REST head.
http://blogs.msdn.com/aconrad/archive/2008/12/15/what-is-iupdatable-why-should-i-care.aspx
I enjoyed this post, thank you. I found it both funny (loved the "metric ass-load" and "throwing up in your mouth a little") and timely.
Many geeks are being let go from their employers in these finacially challenging times, but the fact is, companies and businesses still need software. The tools and ability to be able to produce software quickly are more important now than ever.
I note the comments about people using other techs could possibly do it quicker. Well, I would have to response with "who cares?" - This particular client wanted an ASP.NET app. They got what they needed in a relatively small amount of time.
a favorite of mine is still LINQ to XML (xml literal)
If you'd done this in EF you would have spent more than an hour randonly clicking in the design surface trying to get it to map things the way you wanted ;-)
So, "Real World Apps in Days not Weeks", eh?
Then explain this line :
"He's spent the last few weeks, on and off, going back and forth"
Weeks, eh?
So what you're saying is that the easy stuff didn't take long? The hard stuff took longer (and I note that you don't even mention the time he spent with his client finding out what to do).
Perhaps metric donkeys can't carry all that big a load after all.
Could you provide us with some more background info surronding the Linq2Sql vs Entity Framework debate?
Why can't the two 2 technologies co-exist, Microsoft has other overlapping technologies so I don't see the big problem.
ASP.NET MVC and WebForms are kind of overlapping technologies as well were MVC is the lean and sleak model (Linq2Sql).
What if Microsoft suddenly kills off ASP.NET MVC development??
I know the MVC team loves using Linq2Sql in their tutorials so I guess you would be in favor of keeping it around and continue evolving the product?
Microsoft has always been pretty good with providing RAD with nice shiny drag and drop demos. However, part of the alt.net movement (which I am just starting to follow) seems to be to rebel against this sort of RAD approach. Ironically, going against RAD in some ways contradicts part of the alt.net mantra of "You aren't going to need it" (YAGTNI).
I'm not advocating one approach vs. another, this just seemed to be an interesting contrast to say Rob's MVC Store Front project.
WPF still seams like the new kid on the block where it tickles the developers fancy but ultimately costs the customer more money. From what I experienced thus far and what I learned from watching Billy Hollis on DNRTV, there is a huge development cost for picking WPF over WinForms at this state in time.
What benefits are you getting out of using WPF for an in house app where a "wow" factor would get old quickly?
Dave Tigweld - This app is (will be) a public application, running on the desktops of whoever wants to run it. I suggested WPF for a few reasons. One, the databinding in WPF is really easy and flexible. Two, I looked at the first comps/mockups for the application and it was clear that this was going to be a very stylized and animated application with lots of transparency. Doing this with WinForms would have involved a lot of hassle, while with WPF, my buddy and I were able to take the flash comps and get the same animations and effects in just a few hours of XAML markup. Also, WPF makes threading easy with its DispatcherTimer.
TT - Yes, look for some more info on this coming soon. I will try to get it all cleared up.
Andrew Conrad - Fantastic, thanks!
1. I honestly can't remember the last CRUD only app I wrote that did not have important business rules that needed to be validated. I know they exists, just haven't done one recently.
2. What did your tests look like. If did not have any, than you provided very little business value in the long run. Once a change needs to be made or a new feature introduced, you have no idea how it will impact the rest of the system. You've only shown that it works today.
3. What's the maintenance story like? If the behavior of the system changes, can I easily make those changes in a verifiable way (ie testable)
This is not at complain. I just want to say we may easily misuse some new technology in production. In that case, more case studies are necessary for demo.
> My friend is doing the development on the side, at night. He's got maybe 40 TOTAL hours
> into this. When I said that he's going back and forth with them over the last few weeks,
> it's over change orders and their unclear requirements, not because of any technical
> difficulty. Sorry if that wasn't clear.
I had assumed that was the reason, as it is always the reason :-) And therein lies my point.
It is not actually all that impressive to have the database stuff working quickly, or a CRUD type UI for an app that has no business logic. They're the easy bits, and have been for decades now.
There are a ton of tools out there that would have gotten the same work done in the same sort of timescale.
I'll be more impressed if the code turns out to be maintainable in the long term. That's where the real expense and difficulty lies in writing software.
Comments are closed.