We'll it's been a long time since my last post, I've been extremely busy over the past few months, both working on The Chaos Filter as well as client work. I have spent a bit of time on some new technologies that hopefully I'll get a little time to do some additional posts. These include Silverlight, Microsoft Office Communications Server Speech Server, and learned a lot from Marshall Harrison of GotSpeech.NET fame. I've also built a nifty little WCF service that does call backs to .NET clients, this could be very interesting.
Any way, I should probably get back on topic...it seems like everyone is going ga-ga for LINQ, yes, I agree this is a very cool technology, but I'm just not feeling the love from the perspective of providing a new set of capabilities we just didn't have before. Maybe it's the type of systems I build that is prompting my skepticism. Most of the systems I would consider are "transactional" or maybe stateless would be a better description. This includes ASP.NET web page processing and other services oriented programming, basically take a bit of information do something with it (talk to the database, store a file transform it, cook it up in a pan) and send something back to the user. That's not to say however that I'm not implementing an object oriented approach. It's just there is a distinct start point, interaction with a whole bunch of objects to do "stuff" and a distinct end point and other than some very simple state and context information (usually stored in some sort of persistence storage such as a DB) I just don't keep state in memory between transactions.
Saying that, let's discuss a different class of application. I'm currently re-inventing an IM server (OK, I got a good reason to do that, but that's not the point). With this IM server, I'm using the WCF service as I mentioned above to make call backs to clients out in the cloud that have initiated a session (still need to understand the plumbing and underlying mechanism here, but again that's not the point). So basically I have a service running in the background, clients connect and open a session, interact with that session and I can send call backs when invitations come in or send out a message to a conversation. What this means is I'm creating almost an In Memory Data Store that contains relevant information to manage these sessions. Basically right now, I've got everything working off of System.Collections.Generics.Dictionary objects where it's fairly simple to do a lookup to get basic state information for what I need. Alright we are three paragraphs into this, I guess I should finally get back to LINQ and how it relates. My in-memory database of state information is starting to get a bit more complicated and I would love a better way to do lookups against this database, I can see the value of LINQ in a BIG-WAY for this type of application, hopefully if you made it this far, you do to. Unfortunately for this application it's a .NET 3.0 app, and I'm not ready to jump to .NET 3.5 to leverage this new technology. So setting aside the using LINQ for relational DB access and the political debate that it brings, is this a valid use for LINQ in things that we just couldn't do before? If so how many of us are writing these types of stateful applications of those of us that are writing these how many of these should actually be stateless and thus minimizing the impact that the new LINQ .NET 3.5 features provide? I'm not proposing I have the answer here, but I'm posing the question...
-ec
No comments:
Post a Comment