Re: Delphi to Visual Studio Conversion Project

Anonymous a écrit :

Amen. And I could tell you stories about why my boss, his boss, and her boss at least should all be fired. And of course, the guy that convinced them to buy into the mess he was selling. At least seven years in the making, probably closer to ten years, and it's not done yet. It should have been scrapped many years ago, but it keeps on breathing. Why? Politics.

It's a complete rewrite too. From VC++ to C#.

Now, I have a story of my present client. We are actually in the middle of a complete rewrite of a Delphi app in C#. Why? Because the present app "evolved", complete with multiple declarations of core functionality, all code on forms, and spaghetti coding like you would not believe. There was no structure to the present app and it is taking them a lot of time to fix bugs that ooze out and they are finding that often fixing one bug can cause others. They have no comprehensive testing strategy other than giving the appp to human testers. Unit testing is impossible because, apart from forms, there are no classes to unit test.

The rewite has allowed them to separate out database access into a persistence layer, so now they can accomodate clients who use differing database backends or need to integrate our software into their existing systems; it also allows the use of a multi-tier strategy as the object broker can be separated out onto a separate server from the database.

They also now have a separate presentation layer, allowing them to be able to design differing UIs like Winforms, WPF or web-based without touching their business logic at all.

Finally, and probably more importantly, all business logic is in the businesss layer and is structured in such a way that it is possible to use unit testing to ensure that both existing code does what it was intended to do but to ensure that any changes/additions don't cause any regressions.

It has taken us just over one and a half person years, spread out over a 3-4 years for budgetary reasons, to write the underlying frameworks and to get to the point where we have about a dozen test business classes complete with their presentation UIs.

Why did we choose C# over Delphi? Well, to start with we did choose Delphi and spent a couple of months designing the fundamentals of the persistence and presentation layers. But we were finding that we were having to write great swathes of code multiple times in order to provide things like typesafe collections, etc.

It was at this point that C# 2.0 came out with the possibility of using generics to allow us to centralise a lot of, well generic, code. It also gave us the ability to bind UI controls directly to properties of objects rather than the rudimentary data-aware controls that Delphi provided. This UI binding ability would also save us a great deal of effort designing the presentation layer.

So why didn't we stay with Delphi? Well, if Delphi for .NET 2.0, with full support for generics, had been around three years ago, that would have been a possibility worth considering. If we were to start on such a project now, then the main consideration would have to be the flexibility of UI support; apart from that, Delphi for .NET would be a far more viable option.

If Delphi for .NET 2.0 had been around three years ago, and it was an acceptable option, then we would still have completely rewritten the application, simply because the way it was originally written has become very difficult to support/maintain/upgrade.

Had the application been better written in the first place, it is doubtful whether the rewrite would have happened, and certainly changing language would not have been worthwhile.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
.

Relevant Pages

  • Re: OOP style
    ... If you have a form, and then some subsidiary dialog boxes, do you create separate units for each of those dialogs, or do you make them as panels that you then display when needed? ... The Code Explorer is also available, for point-and-click navigation (but I don't use that since it would often stop working in Delphi 5, and I haven't gotten around to trying it now in Delphi 2005). ... In the interface section, I alphabetize a class's methods, and the visibility sections are always in the order private, protected, public, published. ... (Incidentally, Delphi 2005 supports nested classes, but not in the same way Java does. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Best Blog Entry in Years
    ... the customers tell me they want to run in a safe environment as .NET code. ... Mixed mode compiler does not help here - and I do not want to rewrite all ... There is no different paradigm between native code and .NET code ... Strikes me as counter intuitive - if you have a large code base in Delphi ...
    (borland.public.delphi.non-technical)
  • Re: Delphi job market - observation
    ... > it is not just .Net conversion but to VS conversion. ... The C standard is to just rewrite ... Delphi 7 code. ... > - cost - for some reasons it is appear that it is smaller cost to do thing ...
    (borland.public.delphi.non-technical)
  • Re: *sigh* how to continue with clumsy code?
    ... Object Pascal used in Borland Delphi isn't it? ... and that FPC does not support class methods of records. ... for-loops are only for numeric types. ... Rewrite the existing code and afterwards try to finish the game? ...
    (rec.games.roguelike.development)
  • Re: VB coverage in new online mag - VB6 or VB.NET?
    ... They are, at best, an insult to VB developers. ... Which is why a lot of long-time VB shops are considering Delphi. ... > to rewrite code if you've been using lots of API calls. ... had MS made a serious attempt to provide a transition there'd still ...
    (microsoft.public.vb.general.discussion)