Is Microsoft digging in the wrong place?
Java developers might feel a sense of unease relating to the number of posts predicting its demise at the hands of .net. However, developers have evolved; at least I know I have. Looking back on my Delphi days, we used to couple visual components to datasets that were then coupled to the database by a SQL statement. Insert, updates and deletes were made using cached updates with SQL statements that were generated from the select SQL. For the most part, unless you were really aware of the issue, transactions were ignored and despite it being an object-oriented language, it made rather shallow usage of the methodology.
Handling validation, corrections and formatting of fields was always a tricky affair and involved data validation code scattered throughout the application. In most cases the code was stuffed into event handlers and reproduced each time it was needed.
Over time, maintenance became a nightmare. If a field name, type or size changed it would break the dataset that was bound to that table or field. It meant having to go and manually refresh the fields on each dataset, and some changes meant having to manually modify each SQL statement that involved a particular table. For the last few years, most of my Delphi gigs have involved maintenance of Delphi applications and each time I was presented with spaghetti code where logic was strewn throughout the application in the unlikeliest of places.
One problem with Delphi is the ease with which applications can be created using a point and click interface, which is always a good thing, except for the fact that it leads to casual and lazy programming. (Un)Fortunately Delphi was never so popular that the masses picked it up, otherwise we could be swimming in a sea of bad code instead of a small lake. I like to think that those who did adopt Delphi as their language of choice took pride in it enough to do a decent job although obviously not everyone did.
Having seen and worked with Java, it is like coming out from under a rock and programming like an adult. We have frameworks that use good OO principles as often as they use ?if? statements. We can use rich ORM models to decouple the application from the database, and we use other layers and Dependency Injection to abstract everything from casual data access to complex processing so we can easily refactor at will and switch out one concrete class for another. Our domain models decouple our view and our logic from our database. The web frameworks became more plentiful and feature rich, and while it gave the developer a dizzying choice, it showed that Java folks were being creative and innovative.
Despite the choice of Java on one hand, and Delphi on the other, Microsoft chose the Delphi style of development. They chose tight coupling between data, logical and view tiers with developer tools that encourage point and click coding and discourage re-use. They chose the route that promotes lazy development and takes the user down the route of spaghetti code. I think Microsoft could have fully embraced true OO values and built it into Visual Studio.
Microsoft has taken steps to amend this with the introduction of the ObjectDataSource in .net 2.0 which allowed developers to couple their controls to lists of objects. They have also released their own action based MVC framework, which puts them only about 10 years behind java, which in software development terms is a lifetime.
There are also efforts to port the best java libraries over to .net such as spring.net and nhibernate that may encourage people to adopt better practices. I have used Nhibernate with asp.net and found it works very well, but I worry that the lack of a ?Made By Microsoft? stamp will keep it on the sidelines in most corporate shops. There are also many developers who will move to .net from VB and Delphi and continue their bad practices without thought and forge new shackles for themselves in a new language.
ASP.net pages are already being shown the door for Microsoft MVC, Winforms has come and gone in favor of WPF. If developers had separated their layers, they can put a new view layer over the business/data layer rather than have to redo many pieces with a new front end. I don?t doubt for one minute that this will be the last major upheaval to .net in the next decade. It seems like few pieces of Microsoft technology has a practical lifespan of more than a few years. Most articles promoting good practices in .net involve shallow OO principles and like Delphi, are relegated to the strange and esoteric. Why write code when I can point and click?
Looking at Delphi?s past and present, I see a future for .net with an abundance of legacy apps that require someone to jump in and untangle all that spaghetti code. It may pay the bills, and in some cases pay them well, but that doesn?t always make for relief from the misery (as a Delphi developer, I would know).
This Delphi programmer has evolved, but it seems that Microsoft has not yet made the leap, and neither have a number of their developers who keep digging in the wrong place.
Ok Saul, go bust a move, but watch out for the dead monkey.
Update : An interesting discussion on this topic has developed in this post on Fredrik Norm?n’s blog.
5 thoughts on “Is Microsoft digging in the wrong place?”
a) How do you explain why ASP.NET is taking market share away from Java-based web apps? People just can’t wait to give up their superior tools?
b) Check out the MVC Framework, a replacement to ASP.NET that you’d probably like better.
I think this problem transcends tools, it’s more about how people are developing apps. People don’t choose platforms for the tools alone. VB gained great market share, as has Excel and access based apps. People are attracted to ease of development, and this is something Visual Studio has by the ton. Java can be complex, something that is not helped at all by the fact that there is no de facto standard unlike ASP.net. Furthermore, in many cases, this complexity serves no purpose. I like ASP, it’s a very straight shooting framework, but it does lend itself to bad application design.
Regarding the MVC Framework, I have had a very brief look at it. It’s interesting that Java moved from action based frameworks (struts, Webwork, Spring MVC) to component based frameworks (JSF and Wicket which are now the two most popular java frameworks), while it’s the other way around with ASP.net.
Regardless, the main point of the post would be that with a properly decoupled back end you can re-use it in either WebForms, ASP MVC, and even WinForms and WPF. Binding directly to datasets means you cannot reuse it on different apps, or even on different forms in a single app.
Microsoft only put out MVC framework to attract “new blood”, their event-driven webforms approach was always superior. Webforms allow complete separation between presentation and business layers which MVC doesn’t. The reasons are as follows: MVC has no tightly-bound codebehind page to reference/modify page controls either directly or inside event handlers. Further to that MVC has no concept of full-featured serverside DOM with integrated stateful persistence mechanism. All this taken together makes MVC somewhat of a toy and based on spaghetti coded views so prevalent in Ruby / Python / Java frameworks that’s exactly what it is. Equivalent aspx pages can be so much cleaner there is really no comparison. So please don’t lecture me that .NET is somehow inherently worse when it comes to preponderance of spaghetti code.
Hi Wheelright, You’ll get no argument from me on the benefits of webforms /component/event driven frameworks over action frameworks.
I’m sure there are ways to implement business logic in a way that is decoupled from the view and used by either the code behind class or the action handler. My primary point is that typically it is not the Microsoft way to write applications like this and they instead direct the developer down the “database datasource bound to the GUI” path. This is not the Java way, and hasn’t been for a number of years, and it’s probably not the Ruby way either since the focus there is on Active Record.
For example getting a paginated list of customers should be separate class that takes the first result, the page size and a session and returns a list of Customer objects. I can re-use that object in my WinForms client, or even in my MVC application.
My secondary point is that ASP makes it a pain to bind the front end to the model. Why can’t I bind to a list of entity objects and use reflection to find out the properties? Instead, I have to resort to wrapping data in data sources or using other DTO-type patterns to make the data presentable to the view which again is the old, and often despised way of doing things.
Take a look at JSF which uses named objects for data binding by creating backing beans (think code behind classes by name) that provide 2 way binding of data.
I should also add that the inability to bind the view to base objects (List or Entity classes) also creates problems when using third party libraries like nHibernate or other entity frameworks, the benefits of which are numerous although debatable.
I do like .net for a number of reasons, I just think that they have missed the point on some of the OO modeling / MVC aspects.
Comments are closed.