david said:
Hi,
I am new in VS.net. We try to migrate our VB6 application to .net. In our
VB6 application, we have a middle tier data access object to handle the
connection and stored procedures' calls. Do we still do middle tier DO in
COM? or in just Assembly? why?
--I guess in large part it depends on how you're writing the application.
Is your goal to try to migrate everything at once? If so, then it probably
makes sense to do everything in .NET. Your back end Teir is where there's
going to be the most pronounced difference considering that you'll want to
use ADO.NET instead of classic ADO. But compartively speaking, this will in
all likelihood have a large impact on your middle tier as the consumer.
With that said, you can create an assembly (or multiple ones) for each tier
which is probably the most straightforward way( however there's a lot more
to architecture then this so I don't want to downplay that angle). You may
want to take a look at the TaskVision application or one of the started kits
in ASP.NET for general guidance on how to set up a particular project. If
getting the project done is your main goal, then you probably want to reuse
as much of your existing application base as possible and migrate the
pieces. You can create wrappers for each of the to hold your place on an
intermediate basis and then move them over whever you have time to fully
rewrite them. The "Why" part of your question will be answered in large
part by the "Why" of your migration in the first place. You'll probably find
that as far as the IDE goes, you can be notably more productive with the
..NET IDE than the old VB6 IDE (granted this is largely a matter of opinion
vs an irrefutable fact) and if you're doing web development, you'll probably
find that working in .NET will be far more productive than say COM/VB6IDE
and Visual Interdev. For this, or the performance boost you get with
ASP.NET over classic ASP, or the new language features, you may want to bit
the bullet and just migrate everything now. On the other hand, the bigger
your existing code base, the more likely it is that you'll want to reuse
what you have and move over the pieces. I know it probably sounds like a
dodge of an answer but the devil will really be in the details. Perhaps if
you can mention some more of the specific challenges coupled with your
reason and philosophy for switchin,g, it'd be easir to provide more
feedback.
Cheers,
Bill
