Использование веб-API и информации о классе

1

В настоящее время у меня есть следующие проекты в решении Visual Studio

  • MySiteAPI - веб-API
  • Шаблон MySiteMVC - MVC 5

MySiteAPI правильно обслуживает данные по http:\\localhost\api и я хочу использовать это в MySiteMVC.

В настоящее время у MySiteAPI есть код платформы Entity. Первые классы для обработки данных.

Я смущен тем, как вывести данные в определения классов на MySiteMVC, поскольку определения находятся в проекте MySiteAPI, а не в MySiteMVC. Также представляется, что Web API нельзя назвать веб-ссылкой для получения информации о классе, в которой я застрял.

Я считаю, что это архитектурная проблема, и я хочу убедиться, что я правильно понимаю, как это сделать, прежде чем я реструктурирую этот проект.

Я не хочу ссылаться на MySiteAPI на MySiteMVC, потому что подобные поражения отделяют эти два проекта. Я стараюсь быть более уверенным в этом.

Вместо того чтобы помещать определения классов внутри проекта MySiteAPI, должна ли создаваться библиотека классов, которая обрабатывает структуру сущности для данных, которые ссылаются на оба проекта?

Если это так, будет ли библиотека классов содержать только определения классов, а проект MySiteAPI будет проектом, который выполняет операции с базой данных через DbContext? Кажется, это то, что имеет для меня наибольший смысл.

В этом случае было бы три проекта

  • MySiteModels - содержит определения классов
  • MySiteAPI
  • MySiteMVC

Оба MySiteAPI и MySiteMVC будут ссылаться на MySiteModels

Это правильный способ сделать это? Есть ли более подходящий способ?

Теги:
entity-framework
asp.net-mvc
asp.net-web-api

1 ответ

2
Лучший ответ

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

Модели определены в отдельном проекте библиотеки классов, например MyProject.Models. В этом проекте есть только POCO, который ничего не знает о проектах WebApi, Mvc или сущности. Они должны быть полностью развязаны и могут использоваться из любых других проектов.

"Проект каркаса сущности" или "данные" определяется также в отдельном проекте библиотеки классов, например MyProject.Data. Этот проект ссылается только на структуру сущностей и проект Модели. Здесь определяется производный класс DbContext. Проект отвечает за подключение и работу над базой данных. Если вы используете некоторые шаблоны, такие как шаблоны Respoistory или Unit Of Work (которые, я думаю, намного лучше, чем инициализация DbContext везде, где вам это нужно), они также могут быть помещены в этот проект.

WebApi и Mvc являются двумя разделенными "клиентскими" проектами. Оба проекта Reference Models, WebApi ссылаются на проект Data и Entity Framework. Но оба клиентских проекта не знают друг друга. Вы можете дать им свои тонкие (dll) зависимости и разместить их на разных серверах, если хотите. Если в проекте MVC будет индивидуальная аутентификация пользователей с использованием идентификатора, он должен ссылаться на другую аналогичную структуру проектов (данные, модели, структуру сущностей, разделенные DbContext) или использовать уже определенные.

Если вы планируете протестировать свой код (я рекомендую его), будет один (или более) тестовый проект, называемый, например, MyProject.Tests. Тестирование проектов, связанных с Models, Data (или поддельной реализацией Data) и WebApi или Mvc зависит от того, что тестируется.

Для DbContext, Repository, Unit of Work и некоторых других классов должно быть немного интерфейсов, которые могут быть помещены в другую библиотеку классов для общих интерфейсов.

Подведем итог:

  1. MyProject.Models - модели данных POCO. Никаких других ссылок.
  2. MyProject.Data - DbContext, репозиторий, блок работы. Ссылка на модели и сущность.
  3. MyProject.WebApi - проект WebApi. Ссылки - модели, данные, структура сущностей.
  4. MyProject.MVC - проект MVC. Ссылки - Модели (дополнительные данные и структура сущностей).
  5. MyProject.Test - тестовый проект. Ссылки - модели, данные (или поддельные данные), проекты тестирования.
  • 0
    Спасибо за объяснение. Я пойду по этому маршруту.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню