Question

appreciate any help with this.

We are currently working on remodelling a legacy project that is now heading towards being too much of a nightmare to maintain. So, we’ve decided to properly normalise the data structure and use Entity Framework 4 Code First development in an MVC 3 project using a repository pattern. The issue we face at the moment is that the legacy application is hosted on a server outside of our main infrastructure for security reasons – therefore all CRUD operations are done via web services, there is no direct connection string to the MS SQL database.

My “proposed” solution is to define my repository contracts, during development there will be a direct connection to the database but once deployed there won’t be (there may be scope to getting that changed later). So, would it be reasonable for me to provide two concrete versions of the repository working to the same contract. One that uses LINQ to perform CRUD operations (development and possible the infrastructure we can move to later) and another version that uses SOAP to pass objects (that would mean my POCOs would need to be defined as Serializable) and perform the CRUD operations this way?

Does this sound feasible or is there a much better way of achieving this?

Thanks!

Answer 1

If you are responsible for developing both client and service part you can use some simple approach:

• Use some shared interface for repository and service client
• When working with remote repository in client inject service client – the service will use repository implementation directly
• When working with local repository in client inject repository directly

By using this approach you will have single repository implementation for both scenarios and your upper level logic will not change. There will be only additional web service layer for remote repository. Your repository will have to encapsulate all data access logic and queries = no linq queries outside of the repository which is not the issue in your architecture because linq queries are not serializable without your own custom development or without using WCF Data Services (but it would have other impacts on your architecture).

Btw. it is not very common to place repository behind the web service. More common is to place whole service layre / business logic behind the web service.