Comments 10
продемонстрирую реализацию архитектуры приложения
А где архитектура-то?
В данном приложении был создан общий Dependency Injection контейнер для ASP.Net MVC и WebApi, что, судя по повторяющимся вопросам на Stackoverflow, является неожиданно сложной задачей. Далее на примере Asp.Net Identity была продемонстрирована регистрация OWIN Middleware, а также создание модуля безопасности приложения. Т.е. в данной статье был заложен фундамент для последующей хорошей архитектуры приложения. Дальнейшее развитие приложения зависит от бизнес логики и несколько выходит за рамки данной статьи.
Общий DI-контейнер — это теперь считается архитектурой? А OWIN middleware — это, конечно, хорошо, только вы не показали, как на его основе решать бизнес-задачи.
Аргументируйте этот тезис. Я могу на основе того, что написано в статье, написать сильно больше одного варианта архитектуры приложения, и не все из них будут хорошими.
Т.е. в данной статье был заложен фундамент для последующей хорошей архитектуры приложения.
Аргументируйте этот тезис. Я могу на основе того, что написано в статье, написать сильно больше одного варианта архитектуры приложения, и не все из них будут хорошими.
Да, вы правы, на хорошем фундаменте можно построить все, что угодно.
Общий DI-контейнер это еще не вся архитектура, однако наличие у WebApi и MVC различных DependencyResolver классов создало ощущение, что надо регистрировать два различных контейнера для WebApi и MVC, поэтому никак нельзя было пропустить тему регистрации единого контейнера для обоих частей приложения.
ASP.Net Identity тоже было выбрано не случайно. Во-первых — это и есть реализация конкретной бизнес задачи — реализация модуля безопасности приложения. Во-вторых в подавляющем большинстве статей этот модуль реализуется с помощью SeviceLocator, о чем я упомянул в статье. В третьих реализация Middleware для логгирования — слишком стандартная задача, а реализация Middleware для кэширования — достаточно большая задача, заслуживающая отдельной статьи. Мне показалось, что это достаточно объёмная задача для примера. Опять же не хотелось, чтобы статья слишком распухла.
Общий DI-контейнер это еще не вся архитектура, однако наличие у WebApi и MVC различных DependencyResolver классов создало ощущение, что надо регистрировать два различных контейнера для WebApi и MVC, поэтому никак нельзя было пропустить тему регистрации единого контейнера для обоих частей приложения.
ASP.Net Identity тоже было выбрано не случайно. Во-первых — это и есть реализация конкретной бизнес задачи — реализация модуля безопасности приложения. Во-вторых в подавляющем большинстве статей этот модуль реализуется с помощью SeviceLocator, о чем я упомянул в статье. В третьих реализация Middleware для логгирования — слишком стандартная задача, а реализация Middleware для кэширования — достаточно большая задача, заслуживающая отдельной статьи. Мне показалось, что это достаточно объёмная задача для примера. Опять же не хотелось, чтобы статья слишком распухла.
В третьих реализация Middleware для логгирования — слишком стандартная задача, а реализация Middleware для кэширования — достаточно большая задача, заслуживающая отдельной статьи
Ни то, ни другое — не бизнес-задачи. Это все инфраструктура, с которой все, будем честными, тривиально.
Весьма голословное утверждение человека, никогда не работавшего с высоконагруженными проектами. Со всем уважением.
А вы возьметесь доказать, что логгирование и кэширование — бизнес-задачи?
Собственно я и не собирался. Тут важно понимание, что OWIN — это Open Web Interface for .Net. Этот интерфейс является заменой стеку IIS с его HTTP-модулями, поэтому практически любая задача, связанная с OWIN Middleware будет инфраструктурной задачей, что не исключает её возможной сложности. Дальнейшее развитие бизнес-логики приложения зависит уже от конкретных требований и задач и, как я уже заметил, выходит за рамки данной статьи.
Заголовок не соответствует, не вижу ничего про клиентскую часть.
Sign up to leave a comment.
Реализация клиент-серверного приложения с веб-интерфейсом с помощью OWIN