A lost programmer seeking for advices...

Question

Hi.

I'm a programmer with high knowledge of Delphi and Borland's tools. I'm currently in a turn over learning C# and .NET.

I'm planning a total rewrite of my commercialized application.

With all thoses technologies available with Microsoft tools, I'm totally lost.

Which way to go? WinForms? WPF? WCF? Asp.NET? Using Microsoft Ajax? JQuery? NHibernate? Strong Typed Datasets? S#arp? Castle? Rhino?

I know all of thoses technologies are not mutually exclusive and compatible, but I would like to know which combinaison are, according to you, the best in the .NET world.

In a nutshell, my app is a database application. I need reporting and the ability to send custom strings to label/ticket printers. In one specific section of the app, I need some graphic manipulation. Like drawing an image and the ability to do mouse operation on this image like trapping mouse up/down/moves. Nothing really advanced, but it's needed. I also need some features of my app to be available on the web...

If you have any advices, tricks, tips, success stories... I really want to get my hands dirty at .NET but I'm having 1G headakes a day reading all the stuff available.

Thanks.

Answer 1

This is a bit too vague to answer really. "It depends".

I take it your app is currently a windows app? Any reason to make it a website? If not, forget about asp.net and lets decide between winforms and WPF.

Now lets think about where you app runs. On your own PC, or on the clients? depending on your deployment options (os, whatever), you'd go with winforms, as it may be more supported, but if you can, go with WPF.

Okay, so with that solved, we move to your database. If you want an ORM, (which you should), I love LLBLGen, but it costs money. IMHO, it's well worth it, but decide for yourself. So with that sorted ...

Unit testing. You probably won't need rhino mocks, as it's more for mocking items that you don't write, but maybe you can. Just get started with NUnit, and as you progress, you will decide what you need to test, and what you don't. Don't worry about learning this upfront.

That's how I would approach it :)

Answer 2

From what you've provided in terms of current-implementation details so far it sounds like you'll want to focus on a desktop (not web) application; and provided that your customers don't object to installing the latest .NET framework then you should focus on using the .NET 3.5 SP1 tools (or even the 4.0 framework, if your expected ship date is ~6 or more months out).

The deciding factor that you've mentioned is peripheral support; namely being able to print to printers. Web-technologies are great for replacing applications to a degree, but peripheral support isn't their strong suit. They might work if you can generate print documents and essentially just "print the page" to the printers, but if you need to do any low-level communication with the printers then a rich-client application is still the powerhorse.

That said, rich-client applications can blur the lines. ClickOnce deployment can handle distributing updates for the application and WebServices can allow you to centralize certain logic).

As for specific technologies; it depends what you're clients will have installed and what your needs are. WinForms will be supported for a fair while yet, but WPF appears to be the path forward; it's seeing ever-increasing adoption and Microsoft is proving it as a serious technology (and not just eye-candy) in VS2010 and other new products. WCF is essentially a revolution of .NET, while Microsoft markets it as the new way to do web-services or as a replacement for existing messaging technologies (more of a wrapper really) the fact is that it brings with it a slew of features and productivity enhancers.

As for the data-layer stuff: ORM's are large and powerful, but also require knowledge to work with properly. If .NET 4.0 is a possible target for you then you can look at EF4, Microsoft's official ORM (the current version isn't quite fully-baked). NHibernate is a mature and stable option as well and provides lots of resources. Typed-DataSets are getting fairly dated though, and are being looked-down upon more and more often.

Answer 3

I came to C# from Delphi a few years ago. I feel your pain. The .NET framework is a monster and it takes awhile to learn your way around. You are where you're supposed to be.

I think you should start with a Winforms application. WinForms is the standard .NET framework for writing desktop apps. It will feel very similar to Delphi's designer. Drag-drop controls onto designer surface and assign properties and events. It's a mature .NET technology.

Alot of people are going to push you toward WPF for desktop development, telling you to write WPF apps and winforms is dead, and such. IMO, The WPF design time experience sucks in VS2008. It's alledgedly improved in VS10. We'll see. Right now, people recommend Blend to design WPF, if you go that route.

I would pick up a book on winforms and a book on ADO.NET. ADO.NET is a bit different than the standard data access functionality in Delphi. Also, Winforms has a much more flexible data-binding than Delphi. You can bind to anything practically in .NET. It's nice change for a Delphi dev. I would use the standard report control to write the reports.

Once you are comfortable with WinForms, I would move on to ASP.NET, WPF, WCF or where ever you want.

Good Luck!

Answer 4

Concentrate on the infrastructure and model, I currently use, and would go with:

• IoC - I use Unity and it works great so far
• ORM - nHibernate + Fluent nHibernate + LINQ for nHibernate
• Glue - Write your own glue to put things together

If you want a web application I'd go with asp.net mvc. Try to get everything working without any javascript whatsoever, and then add jQuery and javascripts to give a better experience, but don't require it.

If you want a desktop application, I'm not sure what I would choose, so I'll let others give advice about that.