NAVmoble - the pocket-sized ERP
Optimized for Microsoft Dynamics NAV and Windows Mobile powered devices

Saturday, March 12, 2005

MVC architectural pattern in ASP.NET

The MVC pattern in general
When talking about presentation framework, it seems that the most popular architectural pattern used is the MVC (Model-View-Controller). The model stands for the application logic - e.g. this is where data structures are manipulated, database and business components are accessed. The View and Controller stands for the user interface of the framework. Conceptually the user interface may be considered as a combination of input and output components. In the MVC case the View and the Controller may be considered as these output and input components. It is very true in HTML/HTTP based environments. The Controller receives the user requests (serves as input) and the View outputs content to the user. This pattern enforces the actual representation (View) to be separated from the application logic (Model).
In the Java community MVC stands also for the original MVC implementation (by using JSP for the controller/view implementation and JavaBean for the Model implementation) which brakes a little bit the idea proposed by the MVC pattern. Later Sun proposed second implementation of the MVC pattern, called MVC2.

The MVC pattern from the ASP/NET tower
Going down from the abstract patterns and closer to the implementation details, we will see that ASP.NET uses an implementation of the MVC called Page Controller. (one may argue if the Page controller should be consider as an architectural pattern or implementation aproach, however it depends on the goals of the analysis). Unfortunately it is not quite useful aproach, when dealing with large complicated applications. I talk about the cases, when we have requirements for a complicated workflow management, aggregation of multiple and heterogeneous backend resources, end-user device specific content rendering, long application lifecycle and frequent business model changes.
In this case another MVC implementation approach is more appropriate. It is called Front Controller. ASP.NET does not propose this kind of MVC implementation, however it provides the tools to build such a framework.
A suitable aproach for implementing a Front Controller is to implement use IHttpHandler interface implementation for controller. The IHttpHandler interface implementations are "plugged-in" the ASP.NET request processing pipeline. They are very clear way to imlpement the Controller pattern.
Here comes an example of a Front Controller implementation
The proposed implementation is a good start playing with a front controller implementation. However it uses *.aspx files to represent a single view. This aproach may introduce quite heavy development effort if we have a large number of views to implement.
And beacause in this case, we will have longer and complicated development period it is more probable to inject more defects in the final solution. One way to mitigate this risk is to use alternative View implementation.
The .NET framework introduces the System.Xml namespace. It implements a large number of classes for Xml manipulation.
This is where we may search for an elegant solution. We'll need to acomplish the following steps:
1. Design custom Xml based declarative language to define our views - Xml schema. We call this Xml View Definition
2. Design and implement Xml View Definition Processor. It may be composed of 2 parts: Xml View Transformation (xslt) and code-based processor. In order to compose our view in ASP.NET format we will execute the following steps:
      2.1. *Convert the Xml View Definition file by using our Xml View Transformation and receive html content.
      2.2. Pass the html content to the Page.ParseControl method and add the list of the controls to the Page.Controls collection
      2.3 **Pass the Xml View Definition to the code-based processor in order to handle additional processing - for example Event Binding,Data Binding...,
* We may have a separate Xml View Transformation for every type of end-user device: IE,Netscape, PDA, smart Phone, e.g.
   and why not XAML
**A lot of work may be done by the Xml Transform Processor by using the XsltArgumentList.AddExtensionObject method to add
   references to .NET classes. These classes may be invoked by the transformation processor during the Xslt transformation        process. This way, we may avoid the need from a separate code-based processor.

Note that this only scratches the complexities of implementing such a framework. In order to have fully declarative views definition it will be beneficial to develop a declarative workflow definition also. This workflow definition should be processed by the Controller. However the benefit from using such a declarative aproach for a View definition may reduce the resources needed to maintain/update the solution in a rapid changing business environment. Of course these aproach has its limitation so pros and cons should be estimated against every particular project.

Following some common pros and cons:
* The declarative views/workflow definition eliminates the need of a complex development knowledge for adding new views to the solution
* The Xml View definitions may give opportunity to support multiple end-user device types.
* Possibility for easier changes in the workflow and views in order to respond to business changes

* Greater development impact during the general framework implementation. It may be not suitable for every project.
* The workflow/view maintainability comes with a performance cost. This may be compensated (a bit ) by utilizing a good caching scheme.
* Implementing a good post back handling is a challenge
* It may be chalenging to embed third party ASP.NET based Web Controls.

Sunday, March 06, 2005

Job Performance and Technology

I've found the following figures, which describes a terrible picture of what is happening on the tech scene. One should be noted that it is may be half of the truth. However it should make us think about the software development processes and the quality of the proffessionals...

"52% of all innovative projects fail and 31% percent of these projects are canceled before producing a single deliverable (Kapur, 1997)."

"On average, professional coders make 100 to 150 errors in every thousand lines of code they write, according to a multiyear study of 13,000 programs by Humphrey of Carnegie Mellon" and although "(s)ystems testing goes on for about half the process and even when they finally get it to work, there is still no design" (Mann, 2002)."

"In the last 15 years alone, software defects have wrecked a ($500 billion) European satellite launch, delayed the opening of the hugely expensive Denver airport for a year, destroyed a NASA Mars mission, killed four marines in a helicopter crash, induced a U.S. Navy ship to destroy a civilian airliner and shut down ambulance systems in London, leading to as many as 30 deaths" while the I Love You virus enabled by Microsoft's decision to allow Outlook to easily run programs in e-mail attachments cost $8.74 billion according to consulting firm Computer Economics (Mann, 2002).

"According to a study by the Standish Group' software projects often devote 80 percent of their budgets to repairing flaws they themselves produced a figure that does not include the even more costly process of furnishing product support and development patches for problems found after the release" (Mann, 2002)."

Saturday, March 05, 2005

Post Quality Control in Software Development

I've read some articles about the Balanced Scorecard ( management concept. It is quite new management idea developed in the early 1990's by Drs. Robert Kaplan (Harvard Business School) and David Norton. It deals with the performance management concept and here are some thoughts on the software development process, which came to my mind... As it is appear to me more of the methodologies and disciplines intended to deal with the software development process, trust too much on the post quality control. A lot of organizations adopts particular software development methodology hoping to improve their product quality. Often the problem actually comes from the "adoption" process. The organizations rely and spent too much effort on performing post quality control activities. Words like "zero defect" and "defect convergence" became a labels for a software project success. However testing, inspecting and simply doing a defect fixing is just not quite effective. Defect fixing may be quite expensive process:

  • it takes time and the user may not use the solution to do his job until the defect is fixed (if the solution is in production)it takes resources (managers, developers, time, money, etc.) and probably these resources will not be paid back by the customer.
  • it is always a risk to make changes - the later during the life cycle, the bigger is the risk.

The post quality control in most of the organization has only one goal - defect fixing. This way the organization continuously spends constant resources on defect fixing but never tries to identify the reasons for the defect injection and decrease the quality control cost. Often people think like "We have this post quality control process, so we will design and implement it fast, cause we chasing deadlines and if we have defects we will fix 'em later"- this psychological trend may increase the cost of the post quality control. And as always the most practices and concepts share common basic ideas, which float around the culture space during a particular time frame. My point is that the reason for these trends in the current development methodologies and practices used is that they are inspired by some world-wide management practices used during the time, when the methodologies were published - Total Quality Management (TQM) for example. What we need is a quite new software development paradigm...

Articles about SOA Messaging Patterns

I found these 2 articles, which discuss SOA messaging patterns(part one and part two) by Soumen Chatterjee. These are very interesting articles indeed.