Port Delphi 7 Data Access to C#

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 t开发者_JAVA技巧o 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.

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.

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.

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.

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?

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.