.NET vNext: Bridging Architectures

Posted on 9/7/2006 @ 12:49 PM in #Vanilla .NET by | Feedback | 3349 views

Next Monday, I will be talking about how .NET vNext affects your architecture at VSLive in New York City. I am flatterred that per public votes, that is the second most anticipated session at VSLive. Thanks for the pressure guys - now I really need to make sure that my demos work ;-).

Also, as Julie Lerman let that cat out of the bag on her ziff davis blog, I will also be at Sofia, Bulgaria at Devreach (www.devreach.com) so maybe I’ll be chit chatting about this around there was well. I know I'll be chit chatting about that while I'm there - on stage or not :-).

.. because I feel .NET vNext will severely change how you architect your applications today.

.. and it is extremely difficult to convey a balanced message, because there are too many obstinate developers who fail to consider “productivity” and “maintainability” hand in hand as an important measure in your architecture.

Thankfully, Microsoft didn’t think that way, and frankly many others didn’t think that way either (heard of ruby on rails?).

The challenge of course remains – How do you provide developers with a means to create architectures that are easy to setup today and solve a business problem, and yet change seamlessly to a full blown architecture as the nature and demands of the business problem increase?

We, in our being acclimatized to poor and legacy development platforms such as .NET 2.0 (stay with me on this), have come up with a way to solve this problem. We like to call them n-tiered architectures, or architectural design patterns such as MVC and MVP. We also like to create “factories” that spew out our objects, and “translation layers” that push our changes back into the database. There is a huge number of ORM tools out there, some better than others that go some distance in making the job easier. But we still try and fit those into our architectural design patterns and we keep the presentation layer so damned disjoint from the underlying database, that a trivial application change needs us to modify 8 .cs files.

How ridiculous is that?

In the spirit of good architecture – that isn’t ridiculous at all, and I agree – this is how I’d _like to_ architect a .NET 2.0 application as well.

Note, I said “like to”. But when a client comes by, and tells me “We need this in 2 days or we are dead in the water”, I do churn up a page using SqlDataSource and “get the job done”. Hey – I got the job done!! Isn’t that what you wanted? So essentially I won the war today, so I can survive for the battle tomorrow.

And that is exactly what happens – I am faced with a battle tomorrow, where my SqlDataSource application now needs to “grow” into an n-tier application.

So the next logical step is to use datasets and tableadapters to atleast get some level of data abstraction in my code. That goes some distance, until finally I am stuck with a mound of code that I wish I had used business objects for. Oh my, the classic dataset versus business object debate.

Now as I said – a lot of obstinate developers who fail to consider productivity as an important piece of architecture will always tend to pick BOs over DS. I disagree with them, though I do wish :

a) Datasets were a bit more usable. So they go further and give me a smooth transition as my application needs grow.
b) Business Objects applications were easier to deal with natively in the framework.

And that is exactly what .NET vNext lets you do.

It bridges these architectures, so –

Quick and Easy applications are a bit more usable than they are in .NET 2.0 and before.
Full blown architectures, the n-tier designs require much lesser work to setup, maintain, and modify.

Obviously the question is “How?”.

It does in in 4 ways, of which I will discuss 3 –

a) LINQ to Entities, and LINQ in general. How this makes your business objects a bit more palatable.

b) LINQ to Dataset. How this was the low hanging fruit that MSFT was wise enough to pluck. How this makes dataset applications more flexible and usable.

c) LINQ to SQL, which I won’t be discussing because I have discussed it already under DLINQ, and LINQ to SQL is only useful where the logical and conceptual models are the same. As I said, there are better chances of finding a hot bikini model who is also a C++ programmer, than that happening, so I am not going to discuss this for now atleast.

d) ADO.NET eF (Entity Framework), and the Mapping Provider – and how that fits in your architecture.

Sound off but keep it civil:

Older comments..

On 9/15/2006 10:36:58 AM Jim Jackson II said ..
Well said! I discussed briefly with Pablo (at VSLive NYC) that my team has created a complete framework that allows logical definitions that seamlessly translate into 'real' business objects. Microsoft kind of stole my thunder but its a real validation that the nature of industrial software is making progress towards "the things that must be done" rather than "how do do anything". I'll be looking in detail at the Entity Framework to see where I can architect a graceful transition from my framework to yours.

I can attest to the value of a properly executed entity framework, in conjunction with a true data abstraction layer. It performs exceedingly fast, is maintainable and will makes business agility a real and inexpensive proposition. In short it is software architecture that justifies itself.


On 9/15/2006 12:49:26 PM Sahil Malik said ..
Hey Jim - did we meet @ VSLive? :)


On 9/15/2006 5:51:56 PM Jim Jackson II said ..
Afraid not. I happened to see Pablo a couple of times alone and grabbed him but all the presenters seemed to be assaulted by attendees. Looked like fund ;)


On 9/16/2006 8:34:59 PM Sahil Malik said ..
Pablo alone? UR KIDDING ME!! I had to take a ticket for 2 minutes of his time (well literally).