Wednesday, September 30, 2009

Use Telerik - It's worth it; Not Infragistics

In Nov/Dec 2007, one of my client asked us to use Telerik controls. At first, I was skeptic and did not want to introduce one more new thing in the project. It was our first 2005, .net 2.0, Ajax project. (I am running behind others in technology ain't i?). Till then we had used 2003, .net 1.1 and very little Ajax.

So, I ignored and when the saw first prototype with all .net native controls, they were so furious (obviously) because none of us were great graphics designers. And it was very poor looking application then.

And I thought let me have a look at Telerik. Woila, it had everything I "did not want to do". (this is positive sentense). I did not want to create stylesheet myself and check how different colors look for a table or button or drop down blah..blah... I did not want to write javascript to add some dynamic value to drop down... did not want to design javascript menus.... and Telerik did everything.

The best part was their Client object Model. They provide very rich set of Javascript classes for the controls that you are using that Javascript becomes fun to program. Javascript was my limitation - and they fulfilled it. Not that I don't know, but I don't like to write big javascript code. Even Firefox's FireBug helped debug the javascript.

In 2008 I got to see Infragistics being used in a project. It was Windows Smart Client project. Now, Infragistics had lots of properties for everything. And all those property names were not intuitive. Like in .net controls you may have some property Visible=true/false. Infragistics won't have that property but instead a method Hide() or Show(). Shortcomings of Infragistics was not in terms of features but more in terms of the usability. We were using Office Green theme for Grids, but everytime we go to set theme, it would reset it.

Then I checked to see if we can use it for Web development. But unfortunately their Javascript object model is not as strong as Telerik's ones. For example, to add a TAB to a TABSTRIP, you can use Javascript in Telerik controls, but Infragistic only does this from Server side. This is a true shortcoming.

The Help documents of Infragistics is very poor; while Telerik help is really helpful.

I finally bought Telerik controls in early 2009 and using it for my clients. They actually like the UI that I create using Telerik.

I am not really paid by Telerik to write this post. This is just my honest opinion.

I hate NetTiers

If Eric Smith reads this, he certainly is not going to like the title. But over the time, the way NetTiers has been used in our project, the team has got so frustrated that I am using the strong "h" word. But I believe the fault is never of the tool but the way tool is used.

I love CodeSmith in true sense. I have used CodeSmith since 2005 when I first found out about it and have always proposed using it wherever I have worked so far. I myself own CodeSmith and have made three other people to buy and use it.

In 2008, I volunteered to join a project that was going through tough times - and one reason I wanted to join was because they were making use of CodeSmith and I thought I can definitely contribute. After joining I came to know that its not 'CodeSmith' that they use, they use 'NetTiers'. You will ask, what's the difference? But there is.

Somewhere in the early phase of the project, someone brought NetTiers to the table mainly for the reason of supporting both WebService and direct access w/o much coding. I believe primary reason of using any tool should not be just avoidance of some work. Because I believe the amount work balances out for the whole life cycle of the project - one or the other way. After introducing NetTiers, following problems started occuring:

* Every developer did not have Code Smith license. And honestly, companies won't buy it for everyone. They had one guy doing the NetTiers generation everytime. Now, he became the bottleneck.

* All developers started depending on the NetTiers generation everytime even a small database change was made. Even if a field is added, they would request NetTiers generation, and until it is done they would have to wait.

* The NetTiers generation caused updating all layers (bussiness objects, data access, comp. layer-services) for all the database objects. So, database changes done by other developers would also creep into main code while their relevant code changes in other layers were not committed. This requires then error fixing, code merge, exclude some source files etc.

* Developers started making temporary database calls right from their presentation layer to avoid waiting for NetTiers and then would forget that some code is not using NetTiers and in turn would fail with web-services.

* Now the real issue: Web-services in NetTiers is over the stored-procedure calls. they are not true business services. So, maintaining transaction over the web-services was next to impossible. I am still surprised why the architect/team leads could not see this on day one? Besides, what good is a call to Stored Procedure via web-service? This kind of feature just misleads people.

* Developers called GetAll().Find() type of method only to make the application slower. They never understood the drawback and noone told them either.

* To Update 100 records, you would have to create 100 objects and XML of those objects is passed over the web-service. Developer were not careful about this fact either.

* The small changes to database like varchar(50) to varchar(100) would also make application fail with some validation errors. And it requires to regenerate the NetTiers.

Most of above issues, as you see are because of lack of understanding by the development team; The facts that I disliked the most was - being dependent on the NetTiers regeneration for any changes. I would like some freedom in a way that if I made some change to db, I would go to specific code/stored procedure and make relevant change. But NetTiers generates so many layers of code that there myriad number of places that one would have to change.

NetTiers may be good for very small systems, or admin applications that one or two people are working on. But you don't want to use it for large systems with bigger teams. Anyhow the budget of large systems and bigger teams would justify having custom business objects/data access layer.

At the same time, I would definitely create Custom templates and use Code Smith to generate the DEO/DTO (Data Entity/Transfer objects) and DAO (Data Access Objects), stored procedures etc.

I surely love CodeSmith for that purpose.