CODEWITHSUNDEEP
c#asp.netentity-frameworkazureazure-mobile-services
zhengbli
zhengbli

Reputation: 712

Share a database between an Azure Mobile Service project and an Asp.Net MVC project

I've two projects in the same solution, and I'm wondering what is the ideal way to share the database between AMS and the Asp.Net website. Also, as they both use Entity Framework of some sort, I found it tricky to keep the models synchronized between projects.

Idea 1: simply let them use the same connection string; but what if I used code-first migration in one project, and the other can't update because its migration history is behind?

Idea 2: doesn't let the Asp.Net website touch the database; let it communicate via HTTP requests to the AMS instead; but would that add additional network overhead for the communication?

Idea 3: create a separate project to contain all the entity framework classes and DbContext, and let both projects refer to it. But as the AMS project requires EntityData classes instead of POCO, it causes unimaginable trouble for me to reuse the model classes in other project. I just can't let the website start once I have all the mobile service nuget packages installed.

Any thoughts?

Upvotes: 3

Views: 573

Answers (1)

David Guerin
David Guerin

Reputation: 76

just a few thoughts on your question,

Idea 1: Will cause you trouble as you suggest when you preform EF migrations going forward. The models in each project may end up being different, EF won't like this. Best to stay away from this solution.

Idea 3: is what I tend to use in projects that aren't too heavy on usage and don't have a large codebase with infrequent updates. Create a single Data Layer project which contains all the EF context and migrations, then reference this data layer in multiple domain layers or front-end layers. This works pretty well and can keep things simple for you. Mobile Services exposes database entities via RESTful APIs so there shouldn't be too much trouble there. The Website should use DTOs and view models to move data around between layers. The only problem I have with this solution is when you update the EF models in one project, you will also have to update and publish the second project as EF models would have changed. To get around this I have automated the build and publish process, just to make the process a little easier to manage. Do consider the life of your solution, you may end up in a case where you're project data models diverge and you end up having two data models within one database. Splitting theses out later into two databases can be very painful when you have to bring the data with you.

Idea 2: In more complex cases, where I'm working on large project and continuously updating the code-base and the project is going to last into the foreseeable future, it's best to separate both services using an interface (which won't change too often) and remove the direct dependence on the shared database. You could as you suggest have the data stored in AMS and then just access it via REST requests from the website. Traffic can grow and may be a problem later depending on the demand of your site and mobile services which may slow down your response times to your website. Though initially, my concern would be in response time to your site from the many hops from the site to the mobile services interface to db then back again. Though you should be able to mitigate the effects with this with a cache for the read data, not the write data though.

What I would do in your situation, to make things easier on the deployment is to combine both the website and mobile services into one solution and host the combined website and API together say on an Azure Website alone, sharing the one data layer containing EF. Thus do not use Mobile Services if you do not have to, depending on requirements of course. ASP.NET can nicely support both under the one roof. This is a little outside of the scope of your question but something that might be useful to consider for your immediate problem.

Upvotes: 1

Related Questions