I have some friends who are 'old-school' VB6 database developers and I was telling them about .NET and its features, specifically ADO.NET.
In our conversation, they brought up the following reasons why they would rather stick with ADO than move to ADO.NET:
The Dataset is disconnected (What if power fails?)
The same amount of code still has to be written
The new options of Dataset, BindingSource and TableAdapter seem confusing
the same code is written programatically access the Database, all that changes is how that command is laid out
I'm looking for answers or reasons why ADO.NET is 'better' than ADO with regards to data access when it comes to Windows Forms applications. What does ADO.NET provide that ADO does not? What does it do better than ADO?
NB: I'd like examples that do not involve LINQ.
On the one hand, if it ain't broke, don't fix it. But on the other - VB6? Really? Sounds like ADO vs. ADO.NET is small potatoes here...
I think the issue is more VB vs. VB.NET and then the whole code-base, skill-set, other-non-technical-considerations come into play here.
ADO is unsupported COM-based technology. VB 6.0 is end of life unsupported technology as of March 2008. DAO, RDO, ADO are all technologies that are nearly a decade past their prime.
ADO.NET is a modern toolset for data access. In particular, LINQ to SQL and the Entity Framework take data access to new heights.
There's nothing wrong with using ADO in legacy VB6 applications. And if these applications are functioning correctly there's no reason to change them.
I don't think anyone programming in .Net will be too tempted to try to use ADO since it feels like such a hack job when you try to. Just let them be.
Simple answer: don't convince them...
Have them look at LINQ to SQL (or better yet LINQ to Entities)
One of the biggest issues that was able to get people to switch to ADO.NET at my day job was the fact that ADO (VB6 flavor) is all COM, you get better performance with ADO.NET.
I'm guessing if the recordset is still connected and the power goes out on the server, the user would get prompted immediately in their app before they continue to enter data that won't get saved?
How about memory garbage collection?
Distributing updates is easier in .net.
I guess if you have a lot of code in VB 6 for winform apps why change? Maybe if you start a new project using VB.NET you can show some other benefits like including multiple tables in a table adapter (Can't say I've taken advantage of that).
I prefer ADO.NET myself, but just for balance, there is one advantage of classic ADO over ADO.NET: it is arguably more usable.
Our customers found it difficult to
use [ADO.NET] because of the extensive
initialisation it requires. Even in
the simplest scenarios, users are
expected to understand complex
interactions and dependencies between
several types... Note that many of these
problems were addressed in the .NET
framework 2.0.
Written by the architects of the .NET framework, in the .NET Framework Design Guidelines 2nd Edition page 25.
Related
I have come to know that there is a code migration wizard, that heps migrate from vb6 to vb.net.
How I can access that in vb2008?
Thanks
Furqan
There seems to be some tool support available.
Still, I would be skeptical to the use of the word migrate if you are making the technology monster-leap from VB 6 to .NET 4.0.
If your VB 6 application is really well designed with core business logic nicely isolated in separate classes, then those parts could perhaps be suited for migration.
But, if someone intends to support and maintain this app for another 10 years, you should consider whether a rewrite is a better option. That way it will be easier to start taking advantage of the efficiency gains provided by the new technology. I don't think there is any migration tool that will convert VB 6 code into e.g. anonymous methods, lambda expressions, linq, reflection and generics.
The need to consider a rewrite is particularly important if your long-lived application has suffered increases in code entropy and complexity over the years causing it to be hard to understand and difficult to maintain.
I need to update (well, rewrite really) a SMALL VB6 application which uses ADO to access a JET database, to a vb.net app in Visual Studio 2008.
My research suggests that I should use LINQ, but it doesn't seem to be possible to connect to JET. If JET is now deprecated, what should I use? Or should I use ADO.NET without LINQ?
Please don't answer SQL Server! - this needs to be an app that end users can install easily in corporate or non-corporate environments, and must not require any ongoing technical maintenance. I started to install SQL Express, but stopped when it required at least 2 system updates, as that will be far too complex for this little app.
Jet has been deprecated but there's a replacement in the form of ACE (Access Database Engine).
However, regarding using it from LINQ. The answers to this question have various suggestions and I've also read somewhere that it might be possible to use LINQ to DataSet to do it. Here's a blog post about it: Querying DataSets – Introduction to LINQ to DataSet but I can't find the link to where I read that someone had had success in using it to access an Access DB.
I'd suggest though, that if there are no clear cut solution for using LINQ, the pragmatic approach would be to just stick to normal ADO.Net and wait with using LINQ until you're sure that you're using a datasource that supports it fully.
Here is a good upgrade tool that is free if your project contains less than 10000 lines of code:
http://msdn.microsoft.com/en-us/vbasic/ff793478.aspx
The general approach you should follow, is first a clean migration from VB6 to VB.NET, and get the .NET version to work exactly as it did in VB6, and then start to look for alternative technologies in .NET. It is easier to convert between different technologies when you have a working .NET application than to manually try to convert directly from VB6 code to alternatives in .NET.
Here are some good reasons to migrate first instead of a manual rewrite:
5 myth busting reasons for choosing automatic migration vs manual rewrite
From the article:
even in the worst case scenario, where you still need to rewrite a certain piece of the application after the automated migration phase, the end result will always be a fraction of the total cost and time.
Just use OleDbConnection / OleDbCommand / OleDbDataReader objects to mimic the same logic that you have in the VB6/ADO code. It will work the same way and not require any more dependencies than your existing app.
These may be of interest:
Which O/RM tool supports Microsofts Access?
http://blogs.msdn.com/b/adonet/archive/2007/01/26/querying-datasets-introduction-to-linq-to-dataset.aspx
Does anyone know if there are any ORM tools or Code Generation tools that work against an Advantage Database?
It would be helpful to know what development environment you use.
For .net:
Microsoft Entity.NET Framework
Telerik
Developer Express (Express Persistent Objects)
For Delphi:
I believe REM Objects has a framework that works with Advantage too.
Probably yes, but you'll need to write a NHibernate.Driver.IDriver implementation.
Don't worry, it's easy. You can start from any of the most simple ones at https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/src/NHibernate/Driver/
Also, you should write a NHibernate.Dialect.Dialect implementation, or you'll only be able to use the basic functionality provided by GenericDialect.
Somebody posted C# source for an Advantage Database NHibernate dialect/driver to the nhibernate-development google group; you should be able to use this with any current ADS ADO.NET provider.
However, you should take note of NH-3078 "TimeAsTimeSpanType issue when using Sybase Advantage Database", which doesn't seem to be fixed yet as of now.
Forgive me if this is a repeat question. I've searched StackOverflow and did not find the answer to my question, so here goes.
We currently have a web application running ASP.NET 2.0 with AJAX Extensions 1.0 and SQL Server 2005 running, is deployed on IIS 6 and developing in VS2005. All works great, but I'm trying to find compelling reasons to migrate. The clients we serve to do not permit plugins in general in browsers, so Silverlight is not a reason for us to migrate. Also, we don't have any plans to migrate to SQL Server 2008 any time soon and ASP.NET MVC is not in the works either.
Here's my reasons to migrate. I would like people to comment on them or add to the list:
I want to work with the newer .NET stuff (and I think other developers would too. Also appealing to prospective employees)
Want to keep the technology up to date.
Extension methods
PageMethods in WebControls
WCF
LINQ maybe (we currently use AutoSproc for our DAL)
ASP.NET AJAX built-in to ASP.NET 3.5 (not really a big deal though)
VS.NET 2008 JavaScript Intellisense
My favorite parts are:
Lambda expressions
Functions available in the
System.Data.Linq namespace:
Where(...), OrderBy(...),
ForEach(...)
Extension methods (add a "ToDelimitedString(...)" to all IEnumerable!)
Visual Studio 2008 is nicer with
HTML/web syntax and debugging,
including the aforementioned
Javascript intellisense and
debugging.
Each of these allow you to write code in a more productive manner.
It largely eliminates the boilerplate "foreach", "if x != null", and other boring constructs.
The javascript intellisense is a huge improvement over anything that's come before. But at the same time it still fails in some very spectacular ways. All in all a good step but not something I've been able to use as much as I'd like.
The extension methods and linq (linq to objects and lambdas, not just linq to sql) are very cool, but since you have an orm already set up you won't use them as much as you'd like either.
WCF is okay, but you're probably not going to re-write your existing services for it.
I think the biggest reason up there is keeping your employees happy and attracting good new ones.
You have absolutely no reason to upgrade, from a business prospective.
You have absolutely every reason to upgrade, from a developer prospective.
Just keep in mind that SQL 2008 is not backwards compatible with SQL 2005, meaning, if you develop something in SQL 2008, chances are, your 2005 platform will barf at it. I just recently experienced this with SSIS packages.
LINQ is a reason to upgrade, even if you don't swap out your DAL, or don't do it for a while. In the product I've been working on lately, our development schedule is such that there's no room to change our DAL to a LINQ-based one for a while yet, but even so I find good reasons to use LINQ-to-Objects and/or LINQ-to-XML in probably 60% of the classes I touch, and I love it.
Everything still runs on .NET 2.0, it's just library and language enhancements and an improved IDE experience, which are made to increase productivity. Increased productivity = justification.
I use LINQ all the time now, every single day. It's not just for your DAL. It's about querying anything, with the same API over top. More generally, lamba expressions provide you with the ability to do some things that are very complicated and take a lot more code without them. Anonymous types are very useful as well.
All the points mentioned are valid.
But as a developer, when facing this kind of question, I always ask myself from the other side.
What is Compelling Reasons NOT to Migrate from ASP.NET 2.0 to ASP.NET 3.5? I find it easier to get myself motivated to upgrade.
The free Microsoft ASP.net Chart control and the new version of Ajax tool kit both require 3.5. If i'm not mistaken.
Is there an OR/M (object relational mapper) that can be used in Classic ASP? Even a simplified class object would be a great help in handling simple CRUD tasks.
Yes I know ASP.NET has many and I use a few of them for ASP.NET sites. However this is a legacy e-commerce site that uses ASP/VBScript and a total rewrite it not a possibility.
You could use .net through COM Interop, and do your ORM in .net. Another option would be to use Code Smith, or MyGeneration and generate VB6 classes.
Here's some VB6 ORM I have not used or researched any of these:
http://www.sparxsystems.com.au/products/ea/features.html
If I find anymore Ill update
There is nothing stopping you from using C# or VB.Net and COM Interop to create a DLL that could be read by your classic ASP page. We have done that several times.
MSDN has two good tutorials on COM Interop.
Try my project called Clapper. Its available on Github. https://github.com/jeremychild/Clapper
I also created a framework, but not is so strong than some frameworks said above,
is a simple but very useful framework and helped me a lot.
It's here:
https://github.com/FelipeNathan/asp-orm
and it's in portuguese
I think IMVHO that ORM is a good choice for small projects but I prefer the easy and direct ODBC connections for larger ones.
All the (good) features of the ORMs can be provided by good RDBMS like Oracle or SQL Server.