Archive for the ‘Thoughts’ Category
I picked up book called The Waite Group’s Object-Oriented Programming in Turbo C++ recently to look at what Robert Lafore was saying about OOP 17 years ago. The book was published in 1991. I’ve just read chapter one at this point, but it was rather interesting.
Before we look at Lafore’s views, lets talk about where we are now.
A fairly common complaint we hear in 2008 is that people write their programs in a very data-centric way. They write objects for the sole purpose of CRUD but the life of the application in is the database. They might throw in bit of inheritance to make their objects feel more OO, but end of the day they are making glorified data containers that map directly to the database tables.
I was recently in an interview where one person admitted that it was easiest to start with the database and work out from there. So their “business objects” were just in-memory data containers for performing CRUD with a few useful utility methods hanging off the objects.
If you talk with people working with NHiberate, people doing DDD, an Alt.Netter or Rocky Lhotka (I realize there are very diverse view in these groups), you’ll get the view that your domain objects or your business objects should be the core of your application. I buy into this view by the way; the database is a good place to persist your data, but it shouldn’t be where you start in application design.
So what was Robert Lafore’s concern with procedural programming? Remember that in 1991 OO wasn’t mainstream. Here is a direct quote from a section called Data Undervalued in Chapter 1:
What [functions] do may be more complex or abstract, but the emphasis is still on the action.
What happens to data in this paradigm? Data is, after all, the reason for a programs existence. The important part of an inventory program isn’t a function that displays the data, or a function that checks for correct input; it’s the inventory data itself. Yet data is given a second-class status in the organization of procedural languages.
He goes on to explain that functions/methods/procedures don’t let you model the world very well. How do you model a windowing system with dropdown menus with just methods? And he is right, there needs to be more than verbs in our programming languages, we needed first-class nouns (beyond local variables) to be able to model the world better.
17 years ago coding was too action centric but Robert claims it should have been more data-centric. Now that OO is fairly mainstream coding is too data-centric, and the claim is that we need to be more model-centric.
None of these views stand on there own. If you took away functions we wouldn’t have programming; if we didn’t have data we wouldn’t have a reason to program. But I think that building out a good model that is object based and is independent of the database is just as important for application design.
What do you think about this progression? Where are we going from here?
I remember learning vocabulary words in middle school and getting tired of making so many practice sentences for the new words. Now I’m working on my vocabulary 15-20 years later and I’m really understanding how valuable those practice sentences were.
Raw memorization of words and definitions don’t stick well in my mind. I process so much information each day that I have to work quite hard to make vocabulary words memorable.
But if I can craft a well-phrased sentence around the word it helps me remember much longer because it gives the word some context. Also, the sentence takes you through the process of using the word well, which helps it stick.
It’s sometimes hard to see how valuable context is because it is so intermingled in what we do, think and say. Context is like the air you breath, you rarely think about it but it is essential.
Here are some words for the you:
profligate – adj – excessively wasteful
execrate – v – to abhor or loathe
perspicacious – adj – acutely perceptive or keenly aware
inveigle – v – to obtain by deception or flattery
You can write sentences for for these words in comments below.
I have to admit that many of my descriptions of ASP.NET MVC have been tied to deficiencies and frustrations in the current ASP.NET Webforms implementation. It is time to start talking less about what it isn’t and to start talking more about what it is.
Michael also points out that it is not likely people will use ASP.NET MVC just so they can use the MVC pattern, since you could come pretty close to MVC with some extra work in ASP.NET Webforms.
The main point of the post was to figure out a good definition of ASP.NET MVC that doesn’t rely on problems in Webforms. And here is where I don’t think he captured what ASP.NET MVC is about. Michael ends up with this definition
“ASP.NET MVC is the evolution of Classic ASP, adding an easier separation of concerns while not using an event based model like WebForms.”
First off, I used Classic ASP successfully for several years, but I don’t think there is enough in common to invoke Classic ASP in this definition. What we typed in .asp pages looked like what you make with .aspx pages in the default view engine, but beyond that I can’t find much similarity.
Second, he ends up counter balancing ASP.NET MVC against the event model. I’m thrilled that most of the event model has gone away with MVC, but isn’t this part of the definition implying that there is a problem with the event model in ASP.NET Webforms? So I think to define what value a company would get from ASP.NET MVC you need to counter balance it against the current Webforms implementation (to a degree). But it definitely needs stand more on it’s own as it grows up.
Anyway, Michael’s post has has really got me thinking. In an interview this week I was explaining to an architect why one would want to use ASP.NET MVC and I think I was able to articulate pretty well why you would want to use it and who would not benefit so much from it. I don’t have a better succinct definition yet.
So what benefits does ASP.NET MVC have for me?
It encourages me to separate out fundamental concerns. I want my tools to encourage me along a successful path. They can’t make me build good applications, but they can give me a good model. Having a View that is just about transforming data into a page (or some other format) is good. There isn’t much temptation to put business, data or flow logic in the view. The Controller accepts requests in a predictable format, finds out what Model it needs to call and says what view to render if necessary. The Model can easily be decoupled from the first two parts.
Routing is a first class concept now giving me a prescriptive way to specify a request format. It’s not an after thought like url rewriting.
ASP.NET MVC certainly flattens out the complex Webforms event model. Any time I can cut unneeded complexity from an application I will. I can’t imagine Webforms without preinit, init, render, etc.
As I do more and more TDD with web development, I know that ASP.NET MVC is easier to unit test.
Can we quite having to write ASP.NET MVC? It would be good to have a shorter name for writing. And yes, I ended my title in a preposition, get over it.
I’ve just rebuilt my main development machine with 64 bit Vista on a quad core. So far I haven’t had any glitches with drivers and I have all of my core development tools installed.
I went through this process a year ago and it was definitely more frustrating then.
UAC isn’t quite as annoying as it was a year ago either. Before it seemed that every important action I would take would prompt another popup. So either I’m being slow boiled to accept UAC or I’m just more patient and receptive to the security feature now.
Anyway, 64 bit Vista has been a good experience this time around and I can use all 4G of RAM with out the 32 bit limitation.
A friend of mine, Arian Kulp, just received the Microsoft MVP award. Arian has been writing for Coding4Fun for quite some time, speaks up at CRIneta periodically and has produced a lot of content in the form of Hands-on-Labs and articles.
John Lam just announced publicly that IronRuby is able to run Rails. It doesn’t run it fast at this point, but it is compatible. Speed and performance will be drastically improved as the project develops. This is a good thing for .Net to be able run Rails; it’s only going to make the .Net platform richer with its available languages.
When I was at RailsConf last May Microsoft was almost completely ignored in the normal part of the conference. I think there was a single session related to installing and deploying on the Microsoft platform.
In the hallways Scott Hanselman and Chris Sells got some good hallway conversations going with Martin Fowler and other ThoughtWorks people. This year and even more in the following year it will be much harder to ignore the Microsoft implementation of the language.
As these two ventures mature, I believe some really great projects will emerge. One project that has unified the Ruby/Rails community is RubyGems. I strongly believe that we need a similar package manager. There has been some talk of this kind of project, but I haven’t seen anything significant yet.
The best of what comes out of these projects will not necessarily be the ability to run Ruby on Rails or imitate it, although running it will be a great milestone. The real action will be from idiomatic home-grown projects.
Twitter is like sending fortune cookie-sized messages on an irc channel you custom build. It’s already bothering me that I just went over 140 characters.
There are really 2 things I need to accomplish as a programmer: write a twitter client and solve fizzbuzz. Then I will be complete. :)
oops, this was supposed to be a tweet.