В дополнение к приложению. и недостатком. (http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips#nAdvantages) определены для N-уровня закрой несколько пунктов основываясь на моем недавнем опыт с подобной архитектурой:
Преимущество:
Поскольку контроллеры являются тонкими слоями и бизнес-логик, хранится в фактических услугах , вы можете совместно использовать Сервисный проект для разных целей, таких как Windows Desktop и т. д. В будущем вы также можете предоставить тот же сервис для Webapi. Следовательно, высокая удобство использования.
- Каждый слой выполняет свое собственное задание и с помощью NInject вы можете легко заменить его. У меня есть отличный пример в моем текущем проекте, где для режима отладки я использую службы Exchange Online для почтового шлюза. Если для выпуска я должен использовать SMTP-службы в качестве почтового шлюза. (Пожалуйста, проверьте недостатки DI adv.).
Поскольку вы следите за интерфейсами для NInject, вы можете использовать Mocks для TDD. Следовательно, вы можете добавить преимущества TDD и DI в свой список.
Код Первый хороший подход для представления вашей базы данных, это чистый и прозрачный подход. Вы знаете, что происходит.
Управление версией базы данных через код является самым большим пунктом продажи.
Недостатки:
Даже если вы логически разделить эти компоненты, но вы не можете развернуть эти компоненты по отдельности. Следовательно, масштабирование может быть достигнуто за счет правильной обработки сеанса. Следовательно, больше работы.
Слишком много файлов CS, по одному для каждого контроллера (1 или 2), служб (1 интерфейс и 1 класс), репозитория (1 интерфейс, 1 класс). Следовательно, в зависимости от вашего приложения он будет интенсивно расти. У меня уже есть более 100 файлов для управления. Но с помощью Resharper вы можете избавиться от этого недостатка и преобразовать его в свои собственные преимущества.
Даже если вы можете писать общие операции CRUD для репозитория, контроллера и служб. Будет время, когда вы закончите путь к тому, чтобы каждый контроллер имел свои собственные услуги и т. Д. ...
- Я нахожу, что валидация будет всюду, но я думаю, что это был для любого N-уровня.
Если вы сначала используете POCO с кодом, то определенно вам нужно хорошо понимать миграцию; Я все еще изо всех сил пытаюсь найти много ответов.
Нет прямого и простого способа вызова функций (например, функции импорта, sp в базе данных сначала - edmx) для первого кода DbContext. Это чисто, но есть много хаков, которые могут потребоваться.
Как и код сначала создает базу данных для вас, поэтому для управления базой данных не требуется контроль над версиями. Тем не менее, я считаю сложным заниматься развертыванием, представлениями, функциями, sp; требуется кодирование.
Что касается производительности, я предполагаю, что это сведена к тому, как вы пишете код.
В целом, я следую точно такой же архитектуре для своего Webapi, и я вполне доволен этой архитектурой.
Спасибо за подробное объяснение ... – DON