how can I future-proof migration of a ADO.net local data layer to a future web based interface (web-service or REST)?

Question

Hi,

BACKGROUND: I am working on a .NET WinForms application now (C#) with an ADO.net database for the data layer.

QUESTION: How an I develop this now such that it would be easy to migrate to a model where the data layer is abstracted via a HTTP web-service or REST interface?

For example would just use of a standard C# interface with a Factory to obtain a concrete implementation of the interface where this uses ADO.net be the best?

thanks

Answer 1

Actually what you wanna do is to make your 2-tier application (Application <--> Database) change into an n-tier system (Application(s) <--> App Server <--> Database).

This is a complex change because you have to think of security, business logic and everything.

One Idea could be to use a third-party library like DataAbstract. This is a complete n-Tier framework, still allowing you features like LINQ to a remote data source and making n-tier development really easy. It also provides a web-service interface to easily access your business logic within the application layer from any source. Going further it provides you with client libraries for the iPhone and also windows mobile that do allow you a faster (because binary) access to the layer. You would need the web service interface only for platforms where DataAbstract is not available for.

Answer 2

You've hit the nail on the head - it's about abstraction. Start out right now by abstracting away from storage-specific semantics in your business logic. Develop a clean, object-oriented DAL and do all CRUD/Query operations through it, and while your object model (or domain model, if you want to recognize a difference between the two) can use concrete classes, your DAL operations should be defined in an interface. Whether you use a factory depends on your particular use case, but if you're developing with this sort of abstraction in mind, it makes sense to adopt an inversion of control container and handle this sort of wiring by dependency injection. There are lots to choose from.

Answer 3

You would never want to abstract a DAL with a REST interface. A REST interface is something that you expose directly to a "User Agent". You would never want your business layer to consume data via REST.

The only exception is if your primary goal is to expose the raw data to some remote third party.