Technology choices: Windows, .NET, and mv.NET
This article discusses why I have chosen to work with Windows, the .NET Framework, and mv.NET for interfaces to MV DBMS applications. Feel free to disagree with my choices but maybe my reasoning will make sense to others who are trying to find their "home" amongst all of the available options.
I’ve used a lot of products over the years. My company isn’t called Nebula Research and Development by accident. I research technologies, compare them to others, and make my decisions about what I like best. I read lots of books in the technical sections of book stores. I can go through just about every section and claim some familiarity with the technologies in that section – though that doesn’t mean I like them or use them. I have tried to understand the most popular technologies at an in-depth level to ensure that I can discuss them with reasonable understanding, perhaps even authoritatively. Of all the products I see, I tend to pick the ones that suit my needs and those of the client base that I approach and represent. As trends change, I tend to shift my focus a bit too, but I do so with reservation and try to never adopt radically different technologies that might not catch on with the mainstream
mv.NET relies on the .NET Framework, which in turn relies on Windows. At a high level someone can fault me for choosing to do most of my development over Windows rather than Linux (for example), but as someone who pays the bills by writing code, I find more companies are inclined to do more sophisticated development over Windows, so that’s my OS of choice.
Why not Java?
People can fault me for using .NET rather than Java, another competent development framework. Java has had over ten years to gain a critical mass of popularity, to be installed in appliances, vehicles, and everywhere else. It has had a tremendous opportunity for mass adoption by the programmers of the world. But it has not indeed been adopted with overwhelming fervor. For whatever reason, applications that you load on your PC are not written in Java – that’s a bell that needs to be heard. It’s either too complex or not "open" enough, or too slow – I don’t know why Java hasn’t been adopted so widely but I do know not one prospect has ever asked me to write Java code for them. Again, as someone who writes code to stay in business, I need to go where the money is, where the popular support is, with products that do capture the imagination of people – and that’s .NET. The .NET Framework includes so much more than Java – when I need to perform some function, the answer is already in the libraries somewhere. The platform independent nature of Java means it does not include many features that are necessary for Windows development. And like I said, my clients (the people who call and offer to pay me to write code) generally use Windows, so I need the most feature-rich tools for that environment that I can get.
Why not Mono?
Mono is a cross-platform implementation of the same spec around which the Microsoft .NET is built. I subscribe to the Mono developer and documentation forums and want to use Mono whenever possible. However, at the moment there are no tools that provide MV connectivity via Mono, only Microsoft .NET. At some point mv.NET may be ported to Mono and I will be first in line to see how that will work over Linux. I’d offer to write connectivity tools, but Mono hasn’t quite caught on in the MV community yet, I guess because MV people still think it’s a Microsoft technology. Without a ready prospect base I simply can’t go through the development effort. Companies also use other products in conjunction with Microsoft .NET, products that are not compatible with Mono yet, this is another consideration. While Mono is highly compliant with the Microsoft .NET Framework there are still bugs in common libraries (namespaces), thick-client (Windows Forms) is not supported except through yet other libraries (Gtk#, Qt#, etc), installation can be difficult, and the software needs to be updated frequently – these aren’t complaints against the software, just facts of life that we need to deal with if we are going to use it. I have clients that insist on using the .NET Framework v2.0, and Mono isn’t quite there yet.. When Microsoft releases .NET 3.0 I’m sure Mono will still be in a catch-up mode, fighting bugs, etc – I can’t quite accept the idea of adopting a tool that is constantly in a catch-up and development stage, I need something more stable, more quickly. So again, while I’d like to be using Mono, my primary development remains in .NET.
Is it all about commercial "buyware"?
People can fault me for wanting to use commercial products like PDP.NET or mv.NET rather than freeware like the D3 Class Library, UniObjects, or UO.NET. I can only recommend products that I believe are stable, well supported, and full featured. See this other article for similar notes, but essentially, the freeware isn’t well supported, certainly isn’t full featured, and COM components aren’t entirely stable in a managed .NET environment either.
So when it comes down to the final two, why mv.NET over PDP.NET? As much as I like the people at Raining Data and wish them well, I haven’t seen a dedication on the part of management to really keep that software moving forward. It’s "generally" good software, written and maintained by diligent and competent people, but it doesn’t have the corporate backing that convinces me that it’s going to be around after my clients have invested in it. Whereas, BlueFinity is aggressively enhancing mv.NET and driving toward a future – that’s the kind of company I feel comfortable recommending to my clients. Even from a pure product perspective, PDP.NET has flaws that aren’t being addressed quickly enough. mv.NET has some small annoyances that hardly anyone but a nitpicker like me would care about – the differences in overall quality and usability have compelled me to shift from PDP.NET to mv.NET. I have clients who have used PDP.NET and they have also shifted to mv.NET. I hope others will learn from our experience without having to go through similar investments of time and money.
To be fair, I should mention the FusionWare products as well, including Direct ADO.Net Provider, Direct mv2SQL, and their ODBC Driver Edition. I don’t have the bandwidth to check out yet another product that has only some of what mv.NET has. I’m a little put-off that FusionWare signed up as an mv.NET Distributor, then cancelled their relationship and came out with a competing product. FusionWare has also seen a little too much drama for my taste – there was the Liberty ODBC thing which even they said anyone would be a fool to use it for updating a database, and there were a lot of politics associated with their General Automation and GA eXpress roots. I just don’t know where they are now or where they will be next year so I’ve been hesitant to get more familiar with them. If I may be a bit overly picayune, it also bothers me that they don’t own the fusionware.com domain, but let some cyber-squatters get it, so they use fusionware.net. C’mon folks, own your name. Also, their Direct ADO.Net Provider is mis-named – the technology is called ADO.NET, all caps.
Selling software I recommend – Chicken or egg?
As to my selling products, I don’t advocate products because I sell them, I sell them because I am already recommending them, and I figure it only makes business sense to get a commission on products that I use and recommend for others. So when Nebula R&D announces a new agreement with a company to sell their software or provide services on their behalf, you have to know that a lot of investigation preceded that event – lots of code installations, lots of testing, and lots of business and technical exchanges that allowed me to get the "warm fuzzies" from working with the company and their people. I have gone through this process with many companies, but have chosen to not sell or support their products. There are many companies that I can’t recommend because the products don’t seem to fit quite right, or the cost is wrong, or maybe there are company politics that I don’t want to expose my clients to. Again, people can disagree, but when I get behind a company and software it’s because I’ve already gone through the "school of hard knocks" that other companies need to go through as part of their own investigations. This is another aspect of what the Research part of Nebula Research and Development is all about – I go through this process so you don’t have to, and hopefully when I finally recommend a product, I hope that it carries the same weight as though you had gone through this process on your own.
So as you see, my prospect base, personal needs and tastes, and perspective on the corporate dynamics of this market have all pointed me in a specific direction. I have no pre-determined agendas, no axes to grind, and I’m not trying to find problems to match the solutions I like to use. For the lion’s share of business problems I have come to see .NET and mv.NET as solid platforms for ongoing development and deployment. Your tastes and experiences may differ. Neither of us are wrong for our choices, we’re products of our environment and we’re free to disagree (if we do).
Now that you understand how I came to this point, I welcome you to read my articles specifically about mv.NET to see if you agree that it will facilitate your development and provide value across a wide spectrum of projects.