Wednesday, October 05, 2005
Is Microsoft Enterprise-Ready?
Is Microsoft Enterprise-Ready?
I happen to come across this article today. This is a common theme that I have come across since I have switched from Java programming to .NET. One observation that I have made is that many government and enterprise level software projects are done using J2EE, a strong competitor for .NET. I still come across many who question if .NET is able to tackle enterprise level software.
Personally, in
Many technical presentations on .NET that I have attended till date, has one common theme to it: quick and easy development via dragging and dropping custom controls from the tool bar, with only a few line of codes to write, and you have a nice use case working. This was more prominent in the recent TechEd 2005, where we see a heavy emphasis on the upcoming Visual Studio 2005. ASP.NET 2.0 has built-in controls for login pages, Profiles that doesn’t require developers to write much code to persist custom information etc; much of these are done declaratively. Very cool features indeed. And these will definitely market well, given that human nature like to seek the easiest way to get things done.
However, I question the viability of these practices. More often then not, these demos seem to advocate against design best practices. For example, for minimum codes to be written, these features show most of the data access being done in the aspx pages’ code behind. What happened to 3-tier design of UI-business-data access? Personally, I feel that these demonstration are misleading; sacrificing emphasis on good design in favor of marketing purposes. I had this developer who joined me recently. She had experiences in .Net and attended many such demos. In her first project, she coded her data access codes in aspx pages’ code-behind. She was using SqlDataAdapter and SqlConnection directly from there. She has not heard of data access layer components, and entities. Try showing this type of coding to a J2EE project team; most probably, they will show you the door.
The MS Enterprise Library has been launched almost a year now. Yet the take up rate of this well-developed library is not high. I attribute this to the lack of emphasis of good design in many .NET developers. One common feedback I hear is this: “Well, the library seems quite complex and add more work than required. Why should I be using this?”
Indeed, for small to mid scale projects, an enterprise framework seems like overkill, and seems to only add unnecessary complexity. Developers very often can get by instantiating hard-coded classes (not using providers and factories in Configuration app block), or by do custom logging to a table in the database, without using the Logging App Block (which allows a variety of log sinks declaratively), or calling SqlConnection and SqlDataAdaptor directly without using the Data Access app block.
Its fine with these practices and they produce the features the users want; only if we are sure that business requirements will not later change. What if customers want to log to MSMQ also? What if the business logic requires calling a different class to handle it? What if the data store is changed from MS SQL Server to Oracle? Well, tons of changes and rebuilt. With a framework like that, we more easily isolate the changes and limit rippling changes throughout the entire solution. I have to qualify this, the framework is neither a silver bullet, nor a panacea for changes in requirements; but it makes it more manageable.
However, I must say that all is not lost. There has been increasing education and emphasis on good design. Patterns and Practices is one such effort, with references and materials for best practices. MS Enterprise Library is another such effort. These points to MS’s recognition of best practices required for developers to go beyond RAD and further into enterprise level computing.
