Совместное использование базы данных двумя приложениями ASP.NET MVC 3 в Azure - PullRequest
Новая
       12

Совместное использование базы данных двумя приложениями ASP.NET MVC 3 в Azure

1 голос
/ 12 февраля 2012

(мне было трудно озаглавить вопрос, поэтому не стесняйтесь предлагать изменения)

Вот ситуация: мы только начали создавать систему, состоящую из двух интегрированных веб-приложений MVC 3, работающих на Azure, с общей базой данных AzureSQL. Есть много причин для запуска двух приложений вместо одного, и я бы предпочел не вдаваться в подробности ...

Первоначально база данных создавалась сначала в коде из приложения MVC "A". 75% сущностей из всех созданных будут относиться к приложению «B», плюс приложению «B» потребуется несколько специфичных для него сущностей.

В настоящее время определяющие сущность классы были извлечены в библиотеку классов, поэтому в приложении «A» реализовано решение для повторного использования в приложении «B». Но я все еще не уверен, как добавить сущности, необходимые для приложения "B" ...

Вопрос : каков наилучший способ управления развитием / управлением базой данных в этой ситуации? В частности, где должно быть определение сущностей? Должен ли мы просто иметь отдельный проект БД, определяющий базу данных и работающий в первую очередь БД? (этот вариант является моим предпочтением на данном этапе).

Поскольку оба разработчика (я и другой разработчик), работающие над этим, являются новичками в MVC и EF, любой совет будет высоко ценится.

1 Ответ

1 голос
/ 12 февраля 2012

Не видя того, что у вас есть, оно не полностью отображается здесь в моем мозгу - но я думаю, что у меня может быть идея на этот счет.

Можете ли вы создать дополнительные проекты, содержащие ваши модели (слой доступа к данным), который имеетваша структура сущности edmx (или сначала код) и шаблоны poco установлены.Этот проект будет совместно использоваться обоими приложениями - т.е. оба проекта получают эту сборку, и оба имеют строку ef connect в своих файлах web.configs.

Другой подход - сначала поместить весь код в один проект (независимо от домена., что угодно. модели) и т. д. Затем ваш код сопоставления входит в ваш проект DataAccess 

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

Теперь у вас есть общие классы poco и один слой доступа к данным.Некоторые рассматривают свои классы poco как свои доменные объекты (с этим проблем нет), и их бизнес-логика переходит в классы poco.Это нормально, если сами ваши объекты Poco остаются постоянными в невежестве, и в идеале вы не хотите ссылаться на специфические компоненты реализации в ваших классах Poco.Хорошая рецензия здесь:

POCO - если POCO означает чистый класс .net с единственными свойствами, где я могу написать валидацию в MVC

Лично мне сначала нравится dbа затем перепроектировать его, используя мощные инструменты EF, чтобы получить модель с первым кодом, как если бы вы когда-нибудь захотели провести интеграционное тестирование, вы можете просто создать базу данных для ваших интеграционных тестов и удалить ее, когда закончите.

...