Just a few more words about the switch from Delphi to C#

Thanks for all your comments to my post about switching from Delphi to C#. Although I didn’t intend to stir up that discussion again, I would like to answer some of the questions and suggestions raised/

I appreciate everyone telling me about teaching C# programmers Delphi. I know it's not too hard; I've done it myself :-) But, the number of programmers out there does reflect the popularity of a platform, doesn't it? And some applicants bluntly told me they didn’t want to work in Delphi. They obviously didn’t get the job, but it did make me think a bit.

But, the lack of programmers wasn't the main reason for us to switch at all. Despite somewhat (...) critical sounds about Microsoft (some of which I tend to kind of share) there is a lot of development in the Microsoft world. Way more than in the Delphi world. Some may be good, some may be not so good or terrible, fact is that there is a lot of effort put in the MS platform.

What really did it for me were two things.

(1) We had to wait for Delphi 2009 for Unicode support, which (IMHO of course) is a major misjudgement. I haven't been able to deliver Unicode software, even though there was a bit of pressure out there. I know for a fact that I did lose sales because of that.

(2) About the same time Delphi 2009 (and Prism) came out, I attended the Microsoft PDC. It opened my eyes regarding to the scale of things. One may not like MS being enormous in size, but there are so many exciting things going on out there, that it made me decide to go the other way.

In fact, I particularly went to check out MS Surface. Just one of those things that MS can do and Embarcadero won’t. That’s not to hold against them, and it doesn’t have anything to do with my choice for C# really, but it did tell me that there was a lot more going on than I really wanted to realize.

Just a quick note on quality of tools: I was getting used to Delphi crashing on me several times a day. It was getting to a point that I did take that into account when starting a days work. I am so glad that is over: Visual Studio hasn’t crashed on me once since I started using it. Not a real argument for the choice either, but I’m glad that’s out of the way.

I will always love Delphi and will be programming in it for the next couple of years, I’m sure. But for the next few generations of our software engine, C#/.Net will be the platform of choice.

Now, that still doesn’t solve those designing issues for me :-) Guess I’ll have to do some investigation.

Bye,

Bart

Contemplating MVC for our software

I’m currently in the process of redesigning our software for a new implementation in C#/.Net. Our current implementation is great of course (…) but some considerations made us decide to move away from Delphi into C#/.Net. I’ve listed the reasons before, but to summarize here is a part of the introduction of our formal business case for going C#/.Net.

Microsoft will always invest more than Embarcadero will

As much as I like the Delphi world, there will be more development into C#/.Net than there ever will be into Delphi/Win32. It’s just a matter of size: MS is way bigger than Embarcadero and the number of developers for C#/.Net will always exceed the Delphi/Win2 group.

There are more C# developers than Delphi Developers

It’s a fact. I had a hard time to find experience local Delphi developers. There are plenty C# developers. To just mention a fact: the Delphi user group that I attended had between 5 and 8 developers on each meeting (every 3 months) and I was presenting on every meeting I attended. The dotned group I recently joined has meetings every month with between 20 and 50 developers every time. And the dotnet group is just one of many C#/.Net groups out there.

And there are numerous other considerations to make the move that I won’t mention here. All of them are commercial and strategic considerations, not technical ones.

So, there we go, we will redesign and implement our software.

Design decisions

There are a couple of little draw back to redesigning and reimplementing software (it will set you back a hell of an amount of money) but there are a couple of good aspects too. You can reconsider some design decisions you made earlier. You can apply new technology if you want to. Stuff like that.

There are two major decisions I am currently thinking over:

1. Will I use DevExpress XPO or will I use the Microsoft Entity Framework for my ORM?
2. Will I implement a ‘simple’ 3-tier model or will I go for a MVC model?

Deciding Object Relational Model

There is a bit of information available regarding the decision between XPO and the Entity Framework. I found Gary’s Blog (by DevExpress) highly informative. It’s been noted here that I am a huge DevExpress fan and am really considering building our software using XPO. But, the fact that Microsoft is behind the Entity Framework does play a role in my considerations. I haven’t gone into great detail investigating either technology (and I think I must to make a sound decision). It will be between those two I guess.

3-tier model or MVC model?

Our current app is more of a 2-tier model. The business logic is implemented next to the user interface and I want to move away from that. I am currently contemplating a MVC model or a ‘traditional’ 3-tier model. Our software will have a WinForms user interface as its main interface and most of the stuff out there is using ASP.Net (which I will use for only part of the editing work in our software).

I found this blog (http://rdn-consulting.com/blog/2008/02/01/selecting-a-mvcmvp-implementation-for-a-winforms-project/comment-page-1/#comment-1663) that kind of sums up my considerations.

I haven’t made any decisions on these issues, so any thoughts that you think are worth sharing are much appreciated.

Bye,

Bart