VB to Python migration
tganss_at_t_dash_online_dot_de-remove-all-after-first-real-dash at yahoo.com
Sat Jan 28 15:16:36 EST 2006
You haven't specified where your main pains are.
Do you have at least rudimentary architecture ?
How often do you have code reviews / refactored your code ?
Have you been striving for good code ? Is it a total mess ?
Guessing only from the number of screens, you probably
have more than trivial amounts of data.
*Based on that assumption*, I'ld move the data FIRST.
Get rid of the JET engine! If you are certain you will
have to support SQL server, make it SQL server and
MSDE/new express version first. Only then (perhaps)
think about adding a totally free database engine.
If not, take your pick but *move the data*.
While you are on it, refactor the old code into something
at least resembling a 3 to 5 layered approach with COM.
Doesn't need to be perfect 100%, but more than 50%.
Then exchange the parts that benefit the most by
implementation inheritance, since VB's interface inheritance
is arguably the "best" technical reason for redundant code.
I'ld guess the business layer[s] would be the next things to convert -
but if your VB-forms are mostly slightly augmented copies differing
only slightly, the GUI actually might benefit most from a rewrite,
if the business rules are written redundance poor.
One of the typical scenarios asking for GUI inheritance
is insurance - customer data is only specific for few fields
and even policy field groupings resemble each other across
similar policies. A "minmally redundant" business layer could
even in VB be implemented without too much sweat- for instance
by having methods overwritten in a inheritance based OOP -
design as name mangled methods on objects responsible across
similar problem domains, keeping the "common" methods clean.
Check your code with a critical eye -
even code forced to be totally OOP for
can be written across a wide spectrum of quality.
If there is nothing which is good enogh to be converted last
or no segregation/layering at all in the current program,
(even if it came from the DOS dinosaurs, there were
"good coding practices" known - some of the old "libraries"
were better decoupled than modern day OOP class libraries.)
get rid of most of the people responsible and start only then.
my 0.02 EUR
> We have a program written in VB6 (over 100,000 lines of code and 230 UI
> screens) that we want to get out of VB and into a better language. The
> program is over 10 years old and has already been ported from VB3 to
> VB6, a job which took over two years. We would like to port it to
> Python, but we need to continue to offer upgrades and fixes to the
> current VB6 version. Does anybody know of ways we could go about
> rewriting this, one screen at a time, in Python, and calling the screens
> from the existing program?
> We are also looking for a graphics toolkit to use. IronPython with it's
> .NET bindings and ability to integrate with Visual Studio looks good,
> but leaves that bad MS taste in the mouth.
> We currently use a MS Access back end and need to migrate to a proper
> SQL server. We need to leave options open for SQL Server (for customers
> who want to use existing infrastructure) and something like MySQL or
> PostgreSQL. But in the mean time, we need to be able to access an
> MSAccess (Jet) database from Python.
> Any answers/suggestions/pointers are greatly appreciated.
> Josh Isted
More information about the Python-list