Jun 28, 2005 04:17 PM
2158 Views
(Updated Jun 28, 2005 04:20 PM)
Continued from Part I of this review (Why at all .Net Framework - I)?
In databse for Distributed Transaction Support you must use ADO , but if your Database is not SQL but ORACLE, then ORACLE will have its own transaction manager, then MTS Distributed Transaction Support is actually not required.
All these is posing a single problem... as difficult Integration and Complex Interoperability.
That is the main reason, that even though all technologies were in place, Market really was not very responsive while considering the development of Enterprise Application with MS technologies.
Ohhhh, I forgot one major aspect of EA, which is the deployment...... All are Windows developers must at some point of time have faced, one version of a Dll re writting another version of the samee....... and then u spend days and nights doing regedit and with those complex UUID....... DLL HELL.... just a reminder....
Key to a successful Enterprise Application Model is the seamless integration among all the layers in the Enterprise App...
Question is how do we achieve that ....... These can be achieved broadly in two ways ...
- First and the Simplest way .... Follow a Single Programming Model across all layers in the Enterprise Application.
This will give you an inherent/automatic capability of integration.
This is what JAVA Follows.... J2EE follows.... Packages classes differs in each layer but the approach remains the same...
- But What the heck ? Why MS is going to have Single Programming Model? Till now MS had host of languages, different ways to achieve Windows DNA programming.... So many diiferent professionals catering to different aspects of Software development, different language experts, different applications deployed and commercialised on diiferent technologies .... How do MS justify the market now? ... Of taking a single programming approach and dumping all others....?
So it was not possible for MS to achieve that ... Problem worsens, how to achieve the objective then...
If we have altogether different Systems working in perfect Collaboration and Harmony when each one is completely different from other, It Simply means that these different Systems have the same Parent.....
Which means that another way of achieving this, is if all these different Systems are built Over a Single Framework, Single Base .... then all these will be inherently Compatible..................
The answer was .NET
But since MS is very fond of maintaining Backward Compatibility.... they have advised two roads....
Use a Same Language to Develop Good 'OL windows App, and the same language to develop next generation Windows DNA app but only in a different runtime environment....
So their two existing offerings Visual Basic and Visual C++ were tweaked a lot to have this fantastic Interoperability...
But in my opinion MS was also skeptical of the fact that these languages are not new , they are just tweaked or enhanced for the new Framework... could be a cause of discomfort...
So why not give another option of an Altogether New Language for the New Framework... C# was the answer...
With .NET my long awaiting Enterprise App Framework from MS has finally arrived. I believe there is a long way to go as we are just in 2.0 beta...... and lot too prove because with the absence of an EA model from MS, market has already good share of J2EE as a choice for EA...
There is lot to speak on the framework, but then the objective of the article was just to emphasize the need of the framework from a Software Architect and Industry point of view....
I would recommend all Windows developers to keep working on the legacy but consider their future in .NET
Thanks
