Ive got a WinForms business application that evolved over th

I\'ve got a WinForms business application that evolved over the past few years. It\'s forms over data with a number custom UI experiences taylored to the business, so I don\'t think it\'s a candidate to port to something like SharePoint or re-write in LightSwitch (at least not without significant investment).

When I started it in 2009 I was new to this type of development (coming from more low level programming and my RDBMS knowledge was just slightly greater than what I got from school).

Thus, when I was confronted with a business model that operates on a strict monthly accounting cycle, I made the unfortunate decision to create a separate database for each accounting period.

Also, when I started I knew DataSets, then I learned Linq2Sql, then I learned EntityFramework. The screens are a mix and match of those.

Now, after a few years developing this thing by myself I\'ve finally got a small team.

Ultimately, I want a web front end (for remote access to more straight up screens with grids of data) and a thick client (for the highly customized interfaces).

My question is: can you offer me some broad strokes architecture advice that will help me formulate a battle plan to convert over to a single database and lay the foundations for my future goals at the same time?

Solution

If you\'re taking this thing to \"the next level\" and have a small team to get started with, you will want to make sure you go back to the drawing board and cover all your bases.

Database

Take a look at what you\'ve built in the past. You need to analyze the projects and come up with a set of features and scenarios that you need to cover. Then work on a database design that will cover these.

DAL

Once you have your database relatively locked down, get to work on what a client would need to access from the database. This would be your Data Access Layer (DAL). Create a library that handles this communication to the database, and possibly, authentication. Take into consideration the client platforms you will work with and how you will be hosting the DAL.

Will you be supporting an offline mode that will need an online sync\\merge?
Will the DAL be hosted on the net\ etwork? If so, that gives you the option of using WCF or OData?
If the clients are always connected, and a web client is a must, the DAL should be web-hosted so that all clients can use the same DAL. This doesn\'t mean you cannot create a new DAL in the future for one-off clients.

Client

This is where you really separate your code bases. If you want to support multiple windows technologies, you\'re better off using XAML as a front end (Win8\\WinPhone8\\WinRT XAML, Silverlight XAML, WPF XAML). However, that doesn\'t work for web unless you target Silverlight (Which is really a client tech). So you will have a different front-end here.

If you separate your UI from the logic code, you will really see a gain in code sharing. Read up on the MVVM (Model-View-ViewModel) pattern for what I mean. Using one of the many .NET MVVM frameworks available would help you out too. It generally geared towards XAML UI but it\'s concepts can help you segregate your code correctly.