Acronym Salad
Joined: 23-Aug-2006
etechpartner wrote:
Otis et al
I have had the pleasure of doing adapter based LLBLGen projects for a number of years and didnt have to worry about Microsoft data access technology. However that seems to be changing. Starting with Linq I find myself more and more looking at the MS Acronym Salad and getting more and more confused.
Is there are decent pattern out there that can deal with utilization of LLBLGen (either via entities or via a Linq Project) - in the areas of ASP.NET, MS MVC, Silverlight, WCF ? Those are the main technology areas I am focusing on.
While WCF is pretty straight forward, with plenty of code examples around, and while MVC is something I can reason out and have enough experience to change in order to work w LLBLGen. I am stumped when it comes to Silverlight , ADO Data Services and passing IQueryable to an RIA app as illustrated in Nikhil Kotharis DomainService examples. http://www.microsoft.com/downloads/details.aspx?FamilyID=76bb3a07-3846-4564-b0c3-27972bcaabce&displaylang=en
I saw some conversations on the forum here that allude to the fact that Silverlight only supports a subset of .NET and therefore its not as attractive of a platform to make changes to LLBLGen to support it. Is that right?
That's right. Silverlight is a client platform where entities might live but data-access code isn't, that's left to a service. So we then have to make the decision to offer support for entities on the silverlight platform which requires a stripped down version of the ormsupport classes assembly and we'll not do that. Instead you've to go the DTO route. This isn't a bad thing, it just doesn't export the entities to silverlight. We've had a lot of work to support CF and it's still a cumbersome platform to get things right also because often there's little memory left and things get out of hand pretty quickly. DataAccess is a thing which has no place inside a silverlight application (it happens on the server/ice) and therefore supporting it would cause a lot of work.
Personally I also think silverlight will fail, as its competition is simply too powerful.
What people often forget is that companies like MS and other big corps release products all the time and most of the time they'll fail and no-one will ever remember them. Only a few will stay. Silverlight is an answer to Flash and jQuery and I think it's simply a product which has been released way too late and has no way of getting traction to replace its competition.
Otis do you, or any of the other senior people on the forum have any thoughts / opinions / ideas on how to manage the same old objective of how do I build the best architecture that allows me to continue to adapt my code to an ever changing smorgasboard of MS technology offerings .
Don't change your architecture just because MS released a new thingy which 'this time' will solve world hunger. Use what works, it will work tomorrow. Take ASP.NET. If you need to display read-only data in a list, and you know a repeater control works great, use it. Why bother with complex extra layers of code which give the same thing? What works well today will work well tomorrow. Sure, some people buy into the buzzword bingo of WF/WCF/WPF/ADO.NET dataservices etc. but frankly these people are always going to do that, so if MS releases a new thing after these, they'll jump ship. They also don't deliver solid stuff most of the time, because they're always working with stuff that's a little rough around the edges.
Especially in these tough times with a financial crisis going on on a world scale, it's critical to be able to deliver quality stuff which works. if you have confidence in your current architecture, and how things are done, use that. Eventually, improve bottlenecks you recognized, painpoints which you might want to see changed, but that's it.
The addition of RIA and cloud computing and Linq has added a layer of complexity that I have yet to reason out and distill into a decent pattern.
It might be a good thing to go to a massive hardware store and check out the screwdriver section. 
Man, how many different screwdrivers there are, there must be a need for every single one of them. . If you need a phillips screwdriver, you go to the hardware store, pick one which looks decent and go home. Do you go out and buy one up front? not likely. If you find it comfortable to write code the way you do now, is there really an incentive to change? Will that bring an advantage? Take for example 'Linq'. If you're not comfortable with the way linq queries are written (which can look awkward sometimes) and dont care about our current query system, why bother? The thing is: it might be nicer in some spots, but it also is more limited than our own query system. Use what works, create that great application for your client and with that prove that you were worth the confidence of the client to choose you instead of your competitor. For example, v3 of our designer still uses winforms, and not WPF. WPF simply doesn't cut it at the moment, and winforms really works, despite the WPF fanboys claiming otherwise. It also was known territory, so we didn't have to invest any time learning WPF.
(RIA stands for rich internet app?)
And can somebody tell me why in the world it makes sense for anyone to put IQueryable into a front end / presentation layer? That just seems plain wrong to me. It seems as though doing that is a purposeful attempt to get around the separation of layers in a typical app. So many examples out of MS show IQueryable on the frontend it really has me worried that I am missing some important clue as to why that would make sense.
Agreed, it doesn't make any sense. But that's MS for you: great demo-ware, and the rest is up to you to sort out.
Joined: 23-Aug-2006