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.
No comments:
Post a Comment