C# Entity Framework / ASP. NET Шаблон проектирования REST и моделей или архитектура решения

Question

Я разрабатываю. NET 4.0 Windows Сервис. Эта служба Windows (это должно быть. NET 4.0) осуществляет обмен данными через REST с ASP. NET Web API. NET 4.5. Хранение данных находится на сервере SQL. Решил сделать доступ к данным через Entity Framework 6 (. NET 4.5). Теперь у меня есть вопрос относительно модели, требуемой для Entity Framework и службы. NET Windows. Если я использую Code-First, он работает -> я могу ссылаться на модель из проекта службы Windows, а также из проекта Entity Framework. Когда я выбираю сначала базу данных, Entity Framework генерирует классы модели на основе базы данных, и у меня нет выделенной сборки. NET 4.0 с классами модели, на которые я могу ссылаться в. NET 4.0 Windows Сервисный проект. Я мог бы создать дополнительную сборку. NET 4.0 и определить классы модели во второй раз, но это очень утомительно и требует много времени.

Каждый квадрат на следующем чертеже представляет собой отдельный проект. на второй иллюстрации ->. NET 4.0 Windows Сервис ничего не знает о модели, поэтому я не могу десериализовать JSON в объекты.

Есть подсказки?

Answer 1

Сущности базы данных не должны отображаться за пределами вашего уровня доступа к данным (в этом случае). Вы можете попробовать создать отдельный домен / ядро ​​уровня, где вы будете хранить свои объекты.

Введение в уровень обслуживания может позволить вам иметь сопоставления между вашими объектами БД, сначала созданными базой данных, и DTO, которые вы, возможно, захотите открыть через веб-API.

Те же DTO должны быть и на стороне сервиса windows. Однако, как говорится в комментарии к OP, вам нужно будет вручную вносить изменения в эти контракты (DTO) каждый раз, когда происходит миграция БД с добавлением / удалением новых полей.

Сначала код - это способ go только что упомянуто в других ответах / комментариях!

Answer 2

Код сначала дает вам гибкость для достижения того, чего вы хотите, и поэтому это предпочтительнее, чем сначала БД.

Сначала код позволяет вам иметь ваши модели где угодно, где DB сначала определит их с контекстом структуры сущности. Если вы действительно хотите разделить их, вам придется приложить дополнительные усилия, чтобы воссоздать их во второй раз, чего вы и хотите избежать. Другого пути нет.