August 2004 - Posts
We generally don’t talk about .NET and J2EE together unless, it's a heated debate as to which is better and why. Recently, I came across two very interesting tools which, sort of glues the otherwise mutually exclusive worlds together. The first of which is MainSoft Visual MainWin, a tool which helps C# and VB.NET developers to develop applications for J2EE platform! Do have a look at the published whitepapers here to see how the magic really happens.
Just to summarize, MainWin integrates with VS.NET seamlessly and has a compiler which converts MSIL code to Java Bytecode, which eventually executes on a JVM. Two impressive aspects of the tool are :
- Accessing JDK classes and EJB components from C# and VB.NET.
- Debugging : MainWin allows you to debug C#/VB.NET applications running on a JVM, using the full gamut of debugging features that VS.NET provides. This is really interesting, considering the amount of plumbing that might be required at runtime.
Isn't this testimonial to the fact that VS.NET is a “high productivity” developer tool? In fact, the first tenet mentioned in the whitepaper of MainWin is "Preserve the Visual Studio Developer Experience".
The next really interesting tool was IKVM.NET, which basically is a JVM for .NET and Mono runtimes. So, this is sort of a converse technology to MainWin. Using IKVM.NET, one can run Java applications on the .NET runtime by converting Java Bytecode to CIL. IKVM comes with an implementation of GNU Classpath in .NET. So, normal C# apps can leverage the entire Java class library. Also, IKVM.NET comes with a tool which converts .NET assemblies to Jar files which can be consumed by Java applications. You can also check out the IKVM.NET weblog here.
I have not really worked with IKVM.NET nor MainWin, or for that matter Java/J2EE. So, I am not in a position to really justify the practical value of these tools (I guess, there should be). But I thought it is worth mentioning about these because, if not for anything else, they can really be appreciated from the academic perspective !
Came across a very interesting article on Future of Assembly Versioning, co-authored by one of my favorite authors - Jeff Richter.
The author runs us through a little bit of history in Component versioning, starting off with COM, where we had an infamous problem commonly termed as "DLL Hell". This problem was tackled in .NET effectively by having Strong Naming, but what resulted was a complicated version policy scheme, the problem which is commonly called "Policy Hell".
The author also mentions how both these issues are (sort of) handled in the forthcoming Longhorn / Orcas releases. It is pretty interesting that there would be two types Assemblies - Platform and Library. The Platform type would need to be used in cases where strict backward compatibility is required. So the onus is on the developer to make sure about backward compatibility. Another interesting feature accompanying Platform assemblies is Interim Roll Back, where, in the event where a new version breaks an application, admins can actually roll back to a previous version. Any later updates to the assembly would automatically roll forward the existing (rolled back) assembly. On the other hand, Library assemblies are used in the case where the developer is free to introduce any breaking changes (or innovate as the author puts it), without worrying about backward compatibility. Do read the article for more..
The author presses the point that there is no set solution to component versioning problems and even the proposed solution might be changed considering the fact that it is early days for Longhorn and Orcas!
Quite a while back, I had posted an article in CodeProject titled "Implementing a Provider Independent Data Access Layer in .NET". This article illustrated the usage of a simple provider factory, with which data access could be made generic or provider independent. The implementation was rather straight forward. Callers of the DAL (Data Access Layer) component would work only with Interfaces present in the System.Data namespace. The actual type of provider to be used in the DAL code would be determined through a config file setting and the provider factory would be responsible for returning instances of the required type .
The advantage of this methodology is that it gives you the option of (almost) seamlessly working with multiple providers like OleDb and ODBC without having to lock onto to a specific implementation like SQLClient. With the obvious advantage and seemingly simple implementation, we all could expect a provider factory to be built into the next version of ADO.NET. Well, ADO.NET 2.0 is here and with it comes the DbProviderFactory class. The implementation is fundamentally similar to the factory we discussed in my article but, there are a few important differences:
Foremost among them is that DbProviderFactory itself is an abstract base class and every provider must provide an implementation for this. The provider to use at runtime is obtained by calling the GetFactory static method of the DbProviderFactories class by passing a string uniquely representing that provider. This string is called Provider Invariant Name and is registered by each provider in machine.config. For e.g. for ODBC provider, it is System.Data.Odbc.
The second important difference is that the new provider model is based on inheritance of a set of base classes present in the System.Data.Common namespace. So, you have SqlConnection derived from DbConnection and so on. However, various IdbInterfaces we saw in v1.0 and v1.1 would still be implemented for backward compatibility. I believe the reason behind this change is that ADO.NET classes will constantly evolve to provide more features in terms of properties, methods and events. Exposing the functionality through interfaces can be an overkill in terms of maintenance in the future, wherein you maintain backward compatibility by retaining the old interface implementation, while you add new functionality by implementing new ones (analogous to COM).
For more information on DbProviderFactory, I would really recommend a good article recently published at MSDN : Generic Coding with the ADO.NET 2.0 Base Classes and Factories. This article explains in detail, all the stuff that I mentioned briefly earlier, with a fair amount of examples too.
Ofcourse, there is a lot more to ADO.NET 2.0 than the ProviderFactory. For a fairly detailed listing refer to ADO.NET 2.0 Feature Matrix. Things that catch some interest here are Provider Statistics and improvements of SQLClient wrt SQL Server 2005.