Geeks With Blogs

Tim Huffam Dotting the I and crossing the T of I.T.

Note this article is primarily based on Microsoft/.Net technologies, although the principle apply to any technology.

Before development of any reasonable business software project begins the following areas need to be nailed down:

  • Application Architecture (application structure)
  • ORM (Object/Relational Mapping - data source access and translation to/from business objects)
  • Base framework (system framework, helper classes, base classes, etc)
  • UI.

There are many tools available that will dictate or guide the architecture and generate ORM and base framework.  Most of them do a very good job and fulfil their base requirement: to facilitate and speed up development.

Unfortunately there is no silver bullet - so the difficulty is choosing the right one.  The definition of 'the right one' will vary based on the application's requirements.  However there are some basic guidelines that will make this decision easier (listed in order of weight).

  1. Policy.  Does your company (or customer) have specific policy that will dictate what you use eg 'We are only a Microsoft shop' - allowing no 3rd party tools.  This may also include things like 'only source compiled by us', which means you must have access to the source code of whatever products you use (this is also useful if you need to sign assemblies using your company's own key).
  2. Security and scalability requirements.  If the application has to scale well, then it should be able to be deployed using an n-tier architecture.  Likewise for security purposes you should not be accessing your data source from your publicly exposed interface eg web apps or web services located in a DMZ should use another tier (an app server), located behind a firewall, to perform data source access.  The caviate to this, is to have your web app/service located behind a firewall, and exposed publicly via ISA Server (which sits in the DMZ and acts as a proxy to your app).
  3. Application requirements and developer preference.
  4. Ease of use - ie how long it takes developers new to the project to get up to speed with using the framework.  This can have significant impact on initial development and ongoing maintenance costs.  Frameworks that use industry standard patterns and underlying system framework code are good for this.

Often the underlying system frameworks are very similar - as most applications require a similar set of core functionality (eg validation, security/authorisation/authentication, string manipulation, logging, etc).  The Microsoft Enterprise Library provides a lot of this out the box and is a good start and some frameworks are based on this eg .netTiers

ORM and UI are large subjects on their own - and everyone has their own oppinion of what to do/what not to do.


Most ORM frameworks will generate code either at design time or runtime.  You will have to determine which is more appropriate to your application - flexibility and performance will be considerations.

Two of the main issues around ORMS are:

  1. Table/data model centric vs domain/business object centric, ie does the ORM generate code based on the data model or the domain model.  This is becoming a more controversial topic these days as traditionally frameworks reverse engineered from the datamodel, generating a class for every table.  This made the code easy to understand - but didn't always match the business/domain model.  The current trend is to model your domain first then generate top-down (this is actually nothing new - it's been around a long time in some of the original OO environments).
  2. For database data sources, is the SQL run in stored procedures or dynamic/inline SQL in your code.  This may be dictated to by policy - eg most DBA's will insist on spocs - however LINQ introduces a, much debated, alternative to this.


How a UI is implemented will be greatly dictated to by functional and deployment requirements - however one must also consider the future of the app.  If it's likely that the app will be around for a long time then you should do your best to split out the UI from any business logic.  This is a long-known best-practice as it will give you flexibility and portability.

Knowing what type of UI's (simple web, rich internet app, winforms, commandline, etc) your app supports is a fairly trivial task.  Choosing a pattern to implement it is not so easy.   One of the most popular patterns for this is the Model/View/Controller (MVC) pattern.  This splits out the core components of any UI.  A more recent pattern is the Model/View/Presenter (MPV) pattern - this is similar to MVC, and is better for unit testing and TDD style development.

A popular approach these days is the 'convention over configuration' style framework.  Spurred on by the success of the RubyOnRails framework there have been some developments in this area in the Microsoft camps - initially by the Castle Project's MonoRail project, and now Microsoft themselves have got on the band wagon with their ASP.Net MVC Framework.  All these implement the MVC pattern. 

A really good article on UI patterns can be found here, and a good comparison of both MVC and MVP can be found here.

I hope this brief overview has helped shine a little light on this, sometimes overwelming, subject and, if nothing else, raise more questions - which I'll endevour to dive deeper into in future posts.



Posted on Sunday, February 17, 2008 3:25 PM C# .NET , ASP.NET , Architecture, Design and Development | Back to top

Comments on this post: Application Architecture, Software Development Frameworks, ORM, MVC/P and the Holy Grail - Part 1

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Tim Huffam | Powered by: