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?

Here's a screen shot showing how an older screen uses DataSets and a newer screen uses EF (I'm thinking this might make it more real for someone reading the question - I'm willing to add any amount of detail if someone is willing to help).

enter image description here

2 Answers 2


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.


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.


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\network? 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.


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.

  • thanks! Are you an architect by trade? I wish we had someone with experience to give concise direction like this. Anyway, the DAL is 90% intranet access / 10% web access - so I suspect a WCF/OData solution is in order. Do you consider a DAL to be a hard gateway to the Database? For instance, what if the client needs a Report that is generated in memory from multiple accesses to the DAL? Would you place that into the DAL itself, or create a module that depends on the DAL? Then the question becomes should clients only interact with that layer or can they freely use either? Nov 15, 2012 at 23:02
  • Don't forget to mark this as answer if you feel it answers your question :) I have done architect, programming and db design within a small team where we all traded roles from time to time so I was exposed to all sides. Lately I've done just what you were looking to do, though as a one man team. Regarding your question about the DAL, I would say yes, it is the gateway to the DB. But the DAL could be mixed in with another layer depending on the size of your project. But that other layer shouldn't provide some sort of shortcut to the DB bypassing the DAL code.
    – Thraka
    Nov 16, 2012 at 0:30
  • @AaronAnodide Also, the report question. That really depends on how you have your solution designed, and the size of it. Generally I think that your business logic layer would generate the report, contacting the DAL as needed and then it would be given to the presentation layer. DAL should focus on giving back data and the other layers handle fixing it up and presenting. There are a lot of debates on how to do it. But it always comes down to what works for you :)
    – Thraka
    Nov 16, 2012 at 0:36

I think you need an abstraction layer between all the accounting period databases and the applications, so your applications see the databases as a single data source. With such a layer in place, you can consolidate the databases or enhance the applications independently.

What form that abstraction layer takes is up for debate. A couple of options came to me:

  • a C# library that handles database I/O which both application inherit
  • a single SQL database that has synonyms or symbolic links to the others

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.