Winform and Database development

Question

The company I work for(as a Solo Dev) is a simple, non-profit org. The majority of the apps I have worked on so far and the majority in the queue are glorified Database front ends. To be honest, half of them could be "Jimmy-rigged" to work in Access. I am not an Access developer though and would prefer not to be.

What I am looking for is some guidance and hopefully a few good book suggestions that focus on this kind of development. There is a ton of stuff out there for ASP.NET database driven apps but not so much for WinForms.

I am really curious as to some best practices in this type of development as well as examples of various things I should be doing both coding and personally that will make my job easier as I build these similar apps over DB's.

For example, should I develop some type of CRUD library to reuse or should I be teaching myself an existing FrameWork, like SubSonic or NHibernate?

What types of Design patterns are useful in this kind of environment? Security practices? Should I be strictly adherring to OOP or is there a different approach for these types of Apps?

I own Troelsen and MacDonalds excellent C# books already; are there more thot would focus more specifically on my situation?

A caveat, the reason most of my Apps are WinForm vs Web is because I need to allow my users to use them in a disconnected state. I have been using Merge Replication for this.

Thank you!

Answer 1

As for books, the bset I know is Windows Forms 2.0 programming by Chris Sells and Michael Weinhardt. Excellent stuff.

As for other guidance - have you ever looked at the Smart Client Software Factory? I've looked - more than once - but can't get myself to really use it for now - seems like a bit too steep of a learning curve - but it might be just the thing for you, who knows?

Other than that - have a look around http://windowsclient.net/ - you get be able to pick something up from there.

Marc

Answer 2

Since marc_s addressed your core question pretty effectively, I'll move on to one of your smaller ones, regarding data-access code.

Generally speaking, I'd recommend going with an existing framework whenever possible. The advantages are many -- for some of these frameworks, generating a complete (type-safe, injection-safe) DAL become trivial tasks, and it frees you up to spend more time developing the correct business logic layer and UI.

As for the various technologies ... I've used and grown (mostly) fond of SubSonic. I have recently developed a couple of minor issues with it, but that just happened to coincide with my company (finally) beginning to adopt .NET 3.0/3.5, and we're switching new development to LINQ-to-SQL. (Even though it's in an on-again, off-again dead state. It happens to be the right answer for the problems we're solving today.) The other big "in-box" .NET 3.5 tool is Entity Framework, which is way more flexible than LINQ-to-SQL, at the expense of a slight loss in ease-of-use. I haven't used NHibernate yet (shame on me) or the Castle tools, so someone else can pick up where I leave off here.

For core design patterns: Yes, you still want to use OOP. You may find some other patterns useful as well. I do recommend building your applications in an MVC or MVP pattern, even though it looks more complicated at first. (Trust me; it's easier than dealing with 1,600-line WinForm backing code files.) I've been known to use Singletons to represent global app settings (although a static class would likely work as well). You might consider using the Command pattern to represent the commands executed by your menus and toolbars, as often they are multiple UIs pointing to the same functionality.

Consider abstracting as many components of your forms as possible to their own UserControls. This allows you to keep the main form code smaller and lighter, and you may find that you can reuse some of those controls on other forms as well.

At the end of the day, the most useful advice anyone can probably give you is to adhere to DRY religiously. This is the one issue I've seen time and time again with WinForms apps -- be anal retentive about refactoring as needed to keep the amount of duplicative code minimal, or even better, non-existent.