Abstracting data connection layers and presentation layers in an enterprise application

Question

We are building an enterprise application in which we will incorporate multiple platforms for user interfaces (i.e. ASP.net webapp, Windows Application, and someday, Mobile Apps) and multiple platforms for back-end databases (i.e. SQL Server, XML, Oracle). An additional neccesity is that these back-end DBs either be centralized and accessed via the web or localized on the client computer and occasionally synchronized to the central server.

Can anyone give advice on how we can abstract the user-interface layer & the data layer so that we can more simply create plug-and-play adaptability between the various UIs and the various choices for DBs? For example: in one case, we may have a web-app running on a centralized server via the internet, and we may have remote machines running localized copies via a windows app. At scheduled intervals, we'd want all machines synchronized so that they can all have near-real-time data.

We also need advice on handling the various connection strings involved so that the only setting that would need changing on any one app would be "local" or "remote", which would then determine the necessary connection string.

Answer 1

I would look at using the provider model to establish the database connections in your application.

I would start by looking at the examples and detail provided in the Microsoft Data Application Block, I think it will help get you part of the way there.

Answer 2

Abstracting the presentation layer is a fairly easy concept once you have the hang of n-tier architecture. Just focus on differentiating "domain logic" from "application logic". Domain logic is common across your different platforms, and application logic is platform-specific. For example, data validation is domain logic (though it's nice when you can do it on the front-end, which makes things more complex, but work with me here...) and deciding what URL to redirect to after some action is application logic. Make sure you put your domain logic at a level that is useable by any platform, and make sure not to put any application logic in your domain layer.

The other half of your question seems like your larger focus, but I would ask for some clarification here, as I can discern two different essential questions.

1. I hope you aren't going for the "holy grail" of database independence. This is always a lofty goal trumpted during the design phase, that almost always, pretty much every time, isn't needed.

   If that isn't what you're going for, then I would suggest that you should know which objects are stored in which persistence medium, and you should avoid the complexity of flexibility and just code your vertical paths in as straight-forward a manner as possible. IE don't code extra stuff into some business class that stores its data in Oracle to enable you to put it into SQL Server "at some point in the future". (I came round-robin back to database independence, didn't I?)

2. The question of caching data locally to improve performance for certain platforms is specific to those platforms and I would suggest you look into Smart Clients and the Caching framework/guidance the MS P&P team has. I've been working pretty exclusively on web stuff for the last couple years, but in 05/06 it was pretty good, and they've been doing lots of work on their Smart Client stuff in the meantime.