Doing Overhaul of Codebase: .NET or Delphi backend? [closed]_问答_开发者

Closed. This question is off-topic. It is not currently accepting answers.

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

I have little experience in C#.NET, but have years in Delphi. Any Delphi + .NET people out there that can provide me some guidance?

Here's the scoop:

I am going to be in charge of a overhaul of the codebase (200,000 lines+). We're going to be creating a full n-tier architecture, with the front end being Silverlight. We chose Silverlight as the front end because it can be deployed in a browser as well as an application with minimal effort, from my research.

I have not been able to find a clear comparison between Remobjects SDK and WCF. The few threads I encountered mention the issues with WCF, such as response times, large overhead, and somewhat snotty responses from MS.

This question is more for the backend. Our current codebase is in Delphi. Is it worth keeping the backend in Delphi, if at all possible? The debate is between using WCF if moving to .NET, or using Remobjects SDK (.NET and Delphi flavours simultaneously) if sticking with Delphi.

Pros of Delphi backend + Silverlight frontend:

Existing codebase: Less time during migration
Existing Knowledge: Developers familiar with our codebase are already familiar with Delphi
Easy Deployment: The single exe/dll deployment is difficult to ignore!
Cadence: The Remobjects SDK has been solid for years

Cons of Delphi Remobjects SDK backend + Silverlight + Remobjects SDK frontend:

Technology: Is it even possible for Remobjects .NET to communicate with Remobjects Delphi with Session functionality?
Knowledge: Other that our few developers, the knowledge of delphi is very thin in our city area.
Project code re-use: We would need to re-develop classes in C# as well as Delphi for use in Silverlight.
Cost: Additional cost in licensing
Future: hard to say when Delphi will collapse

Now for the WCF .NET.. Pros of WCF .NET backend + Silverlight frontend:

Project code re-use: A class can be used in both the backend and frontend
Technology: Its already proven
Knowledge: Our city area loves .NET, so there is lots of talent available to hire.
Future: Everyone knows that MS is making tons of money off .NET and VS 2010. This adds some stability to the .NET architecture.

Cons of WCF .NET backend + Silverlight frontend:

Existing Codebase: Our entire codebase would need to be redone, aside from class structure references.
Deployment: I myself have not deployed a WCF application, but I know its more complicated than Delphi.
Cadence: Microsoft is notorious for changing the game as soon as the industry settles. Happened to COM, when will it for .NET?

What would be the ideal situation? After writing this all out, its looking like C# backend is the winner, due to the lower costs and higher chance of a stable future. Whichever backend we use now will be the method of choice for all projects in the future.

What are your experiences with implementing your WCF n-tier application?
开发者_运维知识库
Are there clear any clear and concise books / articles that outline WCF's usage, and best practices when designing your application?
Is there a better solution than WCF in this situation?

Sound off your thoughts!

Joel on Software has a pretty good article about rewriting from scratch (http://joelonsoftware.com/articles/fog0000000069.html). I'm not sure if that completely applies to your situation, but the gist of his article is don't rewrite, ever. You have years of work and bug fixes already in that code, and rewriting it in another language simply won't be able to cover all of those fixes. My recommendation would be to find a good way to interface your Delphi back-end with the new Silverlight front-end. That being said, I've never done any interfacing with Delphi, so you're on your own from there.