Port Delphi 7 Data Access to C#

Question

We have a client/server application written in Delphi 7 with a Firebird back end database. The code originally started out with a data access layer but quickly disintegrated to data access in forms and different units scattered through the project.

We would like to move to .NET at some point in the near future and in my opinion the best place to start would be to move the DAL in .NET first and have the current Delphi app implement it. Then we can further port the business layer and finally the UI.

So I'm looking for some ideas from other developers on some technologies/frameworks to look into for moving the DAL into .NET. My first thought would be to create some web services. The idea is to move the current client/server application to .NET. We can battle multi-tier design, web application stuff later. Maybe the correct answer is to start from scratch?

Any thoughts or ideas would be greatly appreciated.

May I seriously ask **why** would you do that? It's a big switch, it's going to take a lot of time to implement, you'll be stuck reproducing existing functionality, *introducing* brand new bugs and no new features for a long time. I assume you've got your eyes on some shiny .NET technology to make this effort worth it. Tell us what that is, maybe knowing what that would help us give better suggestions. Please note I'm no .NET retractor; I think .NET is nice, and I'm sure I'll use it in the near future, but I'm not going to port my Delphi apps, not in the foreseeable future. — Cosmin Prund, Apr 21 '11 at 10:17
@Cosmin: ... I'd compare it with climbing Mount Everest: people do it because they can ;) ... and separating business logic from UI layer(s) is not a bad idea, providing it to web and mobile clients from a central server brings new use cases, and it is fun to learn something new (as long as plenty of time and resources are there). But I also recommend to read "Things You Should Never Do, Part I" http://www.joelonsoftware.com/articles/fog0000000069.html — mjn, Apr 21 '11 at 14:49
Why don't you fix the Delphi app? Do you seriously think it will be better? Magically? It won't. The same forces at work, will happen again. Unless you find out what caused your Delphi app to go off the rails, you'll repeat the same thing in C#, or worse. — Warren P, Apr 21 '11 at 19:44
Don't. Doing a rewrite costs about as much as you have invested in the old product. So a few years from now, you have the same product, but with different bugs, and lost a few years. — Jeroen Wiert Pluimers, Sep 18 '12 at 19:12

score 5 · Answer 1 · answered Apr 20 '11 at 22:24

There's no magic recipe for that. I'm also a Delphi developer who's now working on the .NET world.

Delphi is about extremes. Every language can have well written or badly written software. But in Delphi, when an app is well written, it's heaven. When it's not, it hell. You know what I mean. Delphi takes RAD to a whole new level. So you can write software really fast. But it grows disorganized... Kinda like WinForms, if you write that SQL Insert command in the Button event :)

Here are my thoughts:

When you're going .NET, go with C#, please. And don't look back.
You should definitively start with the data layer.
If you are to keep your Delphi UI for now and get them working with your .NET DAL, you might even surprise yourself not wanting to change to WinForms. Some people might get upset with this, but time will tell...
You might want to implement you DAL as WebServices. There's a lot of learning opportunities on both side of your software. And there's also reusability!
Start your DAL from scratch. You will not regret.
Do not start UI from scratch. Try using your existing UI. UI takes time. If you are to review all your existing screens, you will get rid of the bad things and then connect to the new .NET DAL. But building everything from scratch is overwhelming and might depress the team in the long term.

score 3 · Answer 2 · answered Apr 21 '11 at 08:46

You can use Delphi Prism.
It isn't really Delphi, but Object Pascal for .NET.

However porting from Delphi to Prism will be much easier because it's both pascal and effort has been made by Embarcadero to make the transistion easy.

Because it uses .NET and not VCL it is not a simple recompile, but you can reuse way more stuff then you would otherwise.

score 2 · Answer 3 · edited May 23 '17 at 11:49

I am in a very similar position. See question

I decided to use WCF at first, but the Delphi WSDL importer just couldn't hack it, I'm now using ASP.net asmx web services, and interoperability has improved vastly.

We're applying a phased migration from a thick client with inconsistent in-line SQL, stored procedures, and up to 900 - 1200 line methods, to a multi-tier solution. Once server side functionality is in place, we move on to implementing the change in the Delphi client. This allows the existing application to continue to work, and testing and deployment can be done in stages.

I started with implementing the DAL, and using Entity framework, we have all our data tables represented as entities, and exchange data with the client using data transfer objects for each entity.

Next the business logic will be migrated functional area by functional area, finally the client, will simply do what a client form should do, allow the user to interact with the application.

One of the main reasons we went with EF was to allow Visual studio to auto generate the delphi classes, with change tracking (still working on that) and data persistence logic by tweaking t4 templates.

There is still one snag: data-binding on the client from a .Net web service is still impossible with Delphi 2010. We are therefore going to leave this until last.

All this will give us the ability to implement bespoke customer requests quicker, against the server, without undermining the client design.

For those asking why, and insisting it is always a bad idea, bear in mind, that in some cases (like mine) these well used applications, are very complex, and not all the Delphi developers are still around to justify questionable design and programming decisions. Currently adding new functionality is always a gamble, when variables have multiple meanings, and for an application of this size the Delphi 2010 IDE has been inadequate, creating a real headache to maintenance, after coming from Visual Studio. Don't get me wrong, I learned Delphi to take on this development, but the way this historical product was written (in Delphi 5), is completely unsustainable.

The question isn't why, but in many cases: how long can you afford to ignore the issue before being forced to carry out a major rewrite, or abandon the product?

Good points. Note that you need some really good .NET/C# developers for your goal. Your Delphi history is absolutely not unique to Delphi: I landed a suite of .NET projects totaling about 4 million lines of code, developed by different groups and companies, some of which wrote brilliant code, but most mediocre at best. Right now we're in a big Windows 7 / .NET 4 upgrade, combined with a piece by piece stabalizing and refactoring stage. — Jeroen Wiert Pluimers, Sep 18 '12 at 19:47

score 2 · Answer 4 · answered Apr 21 '11 at 12:30

This looks like something where DataAbstract can be useful. It offers .Net and Delphi support (and more, Java is in the pipeline already).

It would allow to create the server using C# and connect the Delphi clients over the DA middleware.

As a first step your app could be moved to a Delphi-based server and client, and when the C/S communication logic is working, you could create an equivalent server in C# and then switch.

Note I am not saying it is a good idea, only showing that technically there is a straightforward way. The whole idea of abstraction layers and middleware is to be more flexible regarding the actual implementation.

This is what we did to communicate with a Java piece: build the Delphi client and a Delphi server mockup. Then the party doing the Java part never delivered in part causing another party to go belly-up. — Jeroen Wiert Pluimers, Sep 18 '12 at 19:50

score 1 · Answer 5 · answered Apr 21 '11 at 19:48

While I think rewrites are always a mistake, you may as well start where you would start with any technology trial: Make a prototype. Install firebird ADO.net connectors, and write your DAL in C#.

Rewriting an existing app is always more work than just fixing your current app. Always. And in the end, you'll lose portability, not gain it.

If I was going to rewrite a Delphi app in something else, and it wasn't even native code, it would be Java, not .net. Even so, I'll repeat my first point; Rewrites are a waste of time, and money, and in any real world business I have ever seen them contemplated, they've ALWAYS been a mistake. Yet people decide to do it, again and again.

Port Delphi 7 Data Access to C#

5 Answers5