Document/View All Over Again…

One thing I didn’t get around to mentioning the other day when I was evaluating if LINQ 2 SQL with the LinqDataSource really is multi-layered or not is my belief that what microsoft has really (re)created for us is the Document/View architecture all over again.

That post was an evaluation.  this post is a rant.  The two have no place together.

So, first, a little history lesson.  Back when we programmed in C++ using the Microsoft Foundation Classes (MFC) we had a framework that we programmed in called “Document/View.”  The idea was that any presentation layer stuff would go in the view and anything that accessed the data would go in the document.  I THINK what we were doing was suppose to be the same as a View/BLL/DAL architecture where the BLL and the DAL were combined into one layer.

The reason I say “I THINK” is because I’m not sure anyone really understood it completely.  What most of us tried to do was to put the presentation layer stuff in the View and data access stuff in the Document and when it came to BLL stuff, we kind of put it where ever we felt like at the time.

The problem, of course, is that when we went back to maintain the code, 80% of the code we needed to work on could be in either the View or the Document.  And when you are working with inexperienced programmers, this is an inefficient use of resources.

The question I keep asking myself as I think about the LinqDataSource and the associated framework is, “has Microsoft gone back to the Document/View architecture?”

I’ve read a few post on the web as I prepared for the videos I produced.  There are several others complaining that we no longer really have a multi-layered architecture.  The response is generally something along the lines of, “No, but that was only a tool to get us where we needed to go.  The LinqDataSource, etc. is a better tool.  Once you understand the new tool, you’ll be ok.

But, I’ve been here before, and while I understand this tool.  I have to ask, what was so wrong with multi-layered that we needed a new tool?  And why couldn’t you have at least addressed the two issues I raise in my evaluation so that Linq was multi-layered, we all basically still understood the model, and we could get on with our code.

I also understand enough about this new “tool” to understand that the less experienced programmers are going to misuse it, or worse get stuck using it and go crying to LAMP land and tell us all how .NET is a hunk of junk.

And who can blame them.

Document/View didn’t work in C++ and whatever you call this new model certainly won’t work unless it is fixed to fit into the multi-tiered architecture that has worked so well for us in the past.

So, my plead to Microsoft is to put a select property in the Data Context classes so we can remove the call to the Select stored procedure from the presentation layer and at least provide an OLEDB implementation so we can swap out databases if we need to.

Related Post

6 Responses to “Document/View All Over Again…”

  • Mihail:

    It seems that DAL is still anyone implementation – I really hoped that LINQ would be the DAL’s way. Few questions:
    1. While I agree with the idea that Document/View architecture didn’t work, I have the feeling that MVP is not the clear cut solution either, too much time is spend in trying to fit the pieces in the right layer, too complicated and I don’t see the benefits – ease of implementation, rapid development, better way of debugging due to the layer separation, etc.
    2. CAB comes in my mind as a developing model, just wonder what are your thoughts about CAB, if any.

  • Dave:

    “It seems that DAL is still anyone implementation ”


    Maybe I’d understand the rest of your comment if I understood that sentence?

  • Mihail:

    Just a bit frustrated on various takes on how to implement a DAL, that’s all.

  • Mihail:

    Clarification – I am talking about designing and implementing Generic DAL framework.

  • Dave:

    If you limit the question to .NET implementation. The best generic implementation is going to be a DataSet filled via a DataReader. This is basically what I’m doing with my DotNetNuke code now. Using the DataSet as my BLL layer gives me the advantage of databinding that I can’t get using other methods and using the DataReader lets me fill it from any database. And, if I need to my fill code really doesn’t even have to use the DataReader. I’ll post something in a couple of days that shows what I’m doing in a bit more detail.

  • Mihail:

    OK, thanks!