1

(I had a hard time titling the question so feel free to suggest edits)

Here's the situation: we have just started building a system which is comprised of two integrated MVC 3 web applications running on Azure with a shared AzureSQL database. There are many reasons for running two apps instead of one and I'd rather not get into that...

Originally, database was created code-first from the MVC application "A". 75% of entities from all created will be relevant to application "B" plus application "B" will need a few entities specific to it.

Currently, the entities-defining classes have been extracted into a class library so within the application "A" solution to allow for reuse in application "B". But I am still unsure how to go about adding entities required for application "B"...

The question is: what is the best way to manage the database development/management in this situation? Specifically, where should the definition of entities be? Should we just have a separate db project defining the database and work db-first? (with this option being my preferred at this stage).

Since both of the devs (me and the other dev) working on this are new to MVC and EF, any advice would be much appreciated.

Dmitry Selitskiy
  • 633
  • 1
  • 5
  • 16

1 Answers1

1

Without seeing what you have its not entirely mapping here in my brain - but I think I may have an idea on this.

Can you create an additional projects containing your models (data access layer) that has your entity framework edmx (or code first) and poco templates installed. This project will be shared by both applications - ie both projects get this assembly and both have the ef connect string in their web.configs.

Another approach is to put all code first into a single project (whatever.domain, whatever.models) etc. Your mapping code then goes into your DataAccess project

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {            
            modelBuilder.Conventions.Remove();
            modelBuilder.Configurations.Add(new CustomerMap());
...
}

You now have shared poco classes and a single data access layer. Some treat their poco classes as their domain objects (theres no problem with this) and their business logic goes in the poco classes. This is fine as long as your poco objects themselves remain persistent ignorant and ideally you don't want to reference implementation specific components in your poco classes. For a good writeup here see:

POCO - if POCO means pure .net class with only properties, where i can write validations in MVC

Personally I like db first and then reverse engineer it using the EF power tools to have a code first model as if you ever want to integration test it, you can simply create the db for your integration tests and remove it when done.

Community
  • 1
  • 1
Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
  • Thanks for the take on this? Will such approach work if two apps are in separate solutions? And if yes then do you think the "data" project should be in one of them or completely separate? – Dmitry Selitskiy Feb 12 '12 at 05:46
  • absolutely they can be in separate solutions, since a project can belong to multiple solutions. If it became a problem then you can simply reference the assembly and keep the project out of each solution, but you should have no problem here. The data project could exist in both if you wanted, or be in its own. thats your call. Also I've made some minor edits above – Adam Tuliper Feb 12 '12 at 06:08