Winforms is not dead

There was a time I was really fascinated by WPF and began to dig into it. Well, you know its learning curve.  I must confess: When I re-discovered the advantages of Winforms, I used more time to improve my Winforms skills than to learn all this cool WPF stuff.

In fact Winforms is finished since .NET 2.0. But I want to share some arguments to use it during the next years, especially when you develop business applications.

1. Time is money, and your customers want you to use it as effectively as possible. Many software companies have a large code base of Winforms applications, helper classes, third party libraries and so on. Also there a many active developers with years  of experience in Winforms. Is your customer willing to pay the bill when you all give it up to sell him a WPF solution?

2. Business environments often use Terminal Services (RDP) to deliver applications. Business environments also often stick to old windows version. We have even customers using Windows Server 2003 and XP. There are many discussions in the Web about WPF on Terminal Servers or on aged operating systems. This is just one of many examples. You get interesting hints about fine tuning your WPF application and your Terminal Server (here you find a case study in German).  – But: My customer does not want to discuss. He wants a solution that simply works, even on his old machines that are very reliable when he is using his specialized branch software that was written in Visual Basic 6 ten years ago. You can say about Winforms whatever you want, one thing is granted: You will get working it on old systems (maybe you have to switch your compiler options to target framework .NET 3.5 or earlier). Will you also be able to do it when using WPF?

3. Microsoft does not actively develop Winforms any more. But it makes no efforts to bury Winforms. Have a look at Visual Studio 2012 (not the Express Version) and .NET 4.5. You do not only have the platform, but you also have a lot of up to date documentation on MSDN and elsewhere.

4. The Winforms Designer: In my opinion this is one of the highlights of Winforms. I have tried several GUI designers on different platforms: NetBeans for Java Swing, Eclipse with the Android toolkit, Visual Studio WPF Designer, Qt Designer for Visual Studio C++. The Winform designer tops all of them: Easy handling, transparent, understandable code generation at design time (good for the performance) and so on. Everything appears very mature and simply works.

5. Databinding is possible: From time to time you hear about the overwhelming possibilities of WPF concerning databinding compared to Winforms. I don’t deny the  flexibility of WPF in this area. But maybe Winforms can do more for you than you thought. The MSDN documentation on Winforms is good in most cases, but for Databinding it was not satisfying for me. As Winforms did not change very much during the last years, one of the older books from .NET 2.0 times maybe helpful (for example this or this). The next version of the NotReallyORM framework will show, how LazyObjects implement the INotifyPropertyChanged and are bound to a Textbox or a ComboBox.

6. Last but not least Winforms applications are cross-plattform. The Mono project supports .NET for Linux, including an implementation of Winforms.

What are your experiences with WPF and Winforms? I would be very interested in hearing controversial opinions.

 

Storing Binaries? In the Database, of course!

This blog is driven by WordPress. As far as I can see WordPress would never try to save pictures, videos or pdf files into its MySQL database – in the database you find only links to the file system. This makes sense to me. I cannot imagine a better way to deliver web pages fast and reliable, especially when you have scenarios with many requests per second.

In my job we normally do not program web pages. Will the principle “Do not store binaries in the database” always fit? I remember the time two years ago when I began to design a document management system. It should store 1.6 million pages per year, with multi-user access in a terminal server environment, powered by an SQL Server database on a 64 GByte machine as back end. The customer’s hardware provider gave me two advices: 1. Use transactions. 2. Store the documents in the database. Well, the system is now working productive for one year, and I am very grateful that I followed his hints.

Today I can warmly recommend storing binary data in the database. It is reliable and stable. You can use complex database transactions that include storing the binary, storing process information, storing foreign key relations and so on. You can easily handle concurrent access. And last but not least: The user experience when saving and retrieving documents is not “very slow”. It is just a bit slower compared to working with documents in the file system. I admit there is one restriction. You should not handle 500 MByte videos this way. The documents I am speaking about are 100 – 500 KByte, mostly PDF format. So this is not a good solution for YouTube…

There is a very good article from Microsoft Research that made me to dare this approach in a production environment. I also included the storing of binaries in my NotReallyORM framework.

What are your experiences on that? So far I have tried it only for Microsoft SQL Server. Would be interesting to know how a MySQL database would behave, for example.

Why I do not use ORM, or: The Beginning

“It’s time to become a real modern software company. We should begin to use an ORM framework in our new projects, maybe the latest version of the Microsoft Entity Framework. Everybody uses ORM nowadays, Microsoft pushes it, why we don’t?” That’s what I told the colleagues in my team some months ago.

It was the time when I began to read books about Microsoft Entity Framework and set up some experimental applications. I was fed up with writing boilerplate code for simple CRUD operations and hoped for some magic that was promised when you use these Entity Objects with data binding. Unfortunately the members of my team were not that enthusiastic about my ideas. You must know: We do a lot with SQL in our development, and we never made bad experiences with these “old school” handmade queries.

After some discussions I thought about my “modern” point of view and asked Mr. Google about some critical writing on ORM. One of the most inspiring texts for me was Kenneth Downs’  essay “Why I do not use ORM” in his blog. There you also find a newer version with some other aspects. Well, this was only the begin of the journey. But it was one of many impacts that led me to start this blog and to try an alternative with the NotReallyORM framework.

So I invite you to share your thoughts with me, to try out the framework, to make suggestions and to ask some questions about mainstream thinking.