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

  • Is LINQ Multi Layered?Is LINQ Multi Layered? Several weeks ago, we discussed the point of Multi-Layered Architectures.  We discussed what a multi-layered architecture looks like, and the problems it solves. Today, what I want to examine ...
  • Computed Columns Using LINQ to SQL ClassesComputed Columns Using LINQ to SQL Classes Last week we looked at the extension points Microsoft has wired into the LINQ to SQL classes and how they can be used to achieve some of the capabilities of the Business Logic Layer (BLL) in a mult...
  • Using StoredProcedures with LINQ 2 SQL ClassesUsing StoredProcedures with LINQ 2 SQL Classes While it is true that LINQ will allow you to write all of your data access in .NET without writing a line of SQL, many organizations have already determined that using stored procedures to retrieve...
  • How to code LINQHow to code LINQ Today we finally put all the code we've been looking at for the last couple of weeks into practice and take a look at LINQ.  Today's example will be relatively brief but once you understand the und...
  • Multi-layer LINQ via Extension PointsMulti-layer LINQ via Extension Points As promised a few days ago, I will be covering multi-layered architecture as it relates to LINQ. The first thing we need to evaluate is how Microsoft intended multi-layered architecture to work.&#...
  • 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.
    Thanks.

  • Dave

    “It seems that DAL is still anyone implementation ”

    Uh?

    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!