Archive for 26th March 2008

New ExtJS + ASP.NET AJAX project

Being an SaaS company from the start (web technologies were chosen to drive our main product), it only made sense for us to eventually completely embrace AJAX. In addition, the original application is basically ASP.NET 1.1, with an inconsistent graphical design. So sprinkling UpdatePanel on top would just add some dynamical elements to an outdated UI design, without any real noticeable changes to the user.

This, among other things, was the reason to go all the way and redo our application using a better UI library – naturally ExtJS was my first choice – I didn’t want to invest too much into proof-of-concept application, or, frankly, lock us into one of proprietary component libraries. Version 2.0 just came out, and their component model is quite mature to build an enterprise LOB (line of business) application on top of it.

At the same time I want to keep some standards in place, and chose to use ASP.NET AJAX for the server side, in the web services area. That way we are developing same web service for our AJAX JSON application and for our SOAP integration, using same code in ASP.NET web service. In fact, it works transparently most of the time, and same service code can be accessed from both types of clients. One other thing it adds is nice JavaScript proxy object support on the client side. In the end, while we are developing the application, we get automatic web services API already developed for our partners.

Thirdly, to cut down on development time, an OR/M is used. Currently it’s CodeSmith’s .netTiers template – which automatically generates DAL, BOL and even "service" layer. More importantly, it creates web service (asmx) file, which can be used as-is, or copied from.

The database backend is MS SQL 2005, as always. However, I made some use of xml column type, based on previous experience, to try and accommodate some clients unique requests, which don’t mandate a separate table schema change. The end result is that the product is generic enough to accommodate different scenarios, and fast enough with little overhead from all the XML parsing – it is only needed when a feature sees minor use in real life (and yes, I do know about xml indexing, but for inserting/updating some overhead is still incurred).

The resulting tiers look like this:

  • ExtJS UI
  • client-side code
  • ASP.NET AJAX JavaScript proxy classes
  • JSON data transfer
  • ASP.NET web service
  • CodeSmith .netTiers business and data objects
  • MS SQL database

 

I am very careful to re-evaluate each of the technologies used in this list – an experienced developer may question each and every one of the choices. There are very good (and possibly better) replacements for ExtJS, ASP.NET AJAX JSON, ASP.NET web services, or .netTiers. But by taking the possible changes into account, it’s not that hard to design a system where all these things can be swapped later on. The only real investment that is made, is made into UI code and database designs. So, for example, any code that we custom-develop on top of OR/M can we migrated to a different OR/M solution – and the objects/field names are still driven by initial database design.

But things have to progress, so while designing for change, we move forward as quick as we can! That’s one of XP mottos – programming only what is needed today, and implementing it as simply as possible. And not being afraid to change later on.

So with that, I’ll finish this introduction into our next generation product, and get back to work :) There are tons of things to learn in all that new tech, and I will try to write about it – most of the user-created code can be found in ExtJS forums, and really all it takes is integration.