#c# #.net #asp.net #asp.net-mvc-3 #dependency-injection
#c# #.net #asp.net #asp.net-mvc-3 #внедрение зависимостей
Вопрос:
Я ищу предложения о хороших способах разработки нового ASP.NET Проект Mvc. Он среднего размера и относительно прост по структуре. Изначально я использовал Spring.Сеть для подключения моих объектов сервиса к правильным конструкторам, но теперь руководство сообщило мне об этом весной.Net или любой другой контейнер IOC не должен использоваться в нашей среде.
У меня возникли небольшие проблемы с поиском хорошего способа настроить это без DI. Я хотел бы иметь возможность назначать реализации служб контроллерам таким образом, чтобы обеспечить низкую степень связи между контроллерами и службами и максимально ограничить зависимость контроллеров от отдельных реализаций служб. Я предполагаю, что мой вопрос сводится к тому факту, что я не уверен, где я должен вручную подключить свое приложение в модели MVC.
Есть предложения?
Комментарии:
1. Мне любопытно, почему руководство продиктовало, что вы не можете использовать DI? Нормально ли для руководства принимать технические решения такого рода для разработчиков? Если это так … запустите.
2. Это хороший вопрос, и я действительно не уверен, что некоторые другие разработчики здесь на самом деле не знакомы с этой концепцией и не хотят ее пробовать, поэтому руководство пока встало на их сторону.
3. Будут ли те же ограничения применяться к использованию среды управляемой расширяемости ( mef.codeplex.com ), поскольку он является частью .Net?
4. Использование инфраструктуры внедрения зависимостей, такой как ninject, делает DI тривиальным. Может быть, вам следует вернуться к этой теме с группой и высшим руководством?
5. @zaq: В этом случае следуйте за человеком, возглавляющим команду, и не вызывайте конфликт в команде. Однако, когда вы можете, разрабатывайте и пишите код, который вы создаете, в соответствии с вашим собственным (самым высоким) стандартом. Другими словами, с учетом внедрения зависимостей (т. Е. Используйте poor mans DI) и поддерживайте свой код модульными тестами. Таким образом, вы внесете свой вклад в написание хорошего программного обеспечения. Другими словами, приведите пример. Когда придет время, тщательно мотивируйте своих товарищей по команде и руководителя команды глубже изучить DI. Я согласен с руководителем группы, что DI кажется сложным (поначалу), но это, черт возьми, стоит усилий.
Ответ №1:
Поскольку вы используете ASP.NET MVC 3 вы могли бы написать пользовательский распознаватель зависимостей. Конечно, вы все равно будете проектировать свои контроллеры, используя интерфейсы в их конструкторах, чтобы ослабить связь между слоями. И затем в пользовательском распознавателе зависимостей, чтобы удовлетворить нелепое требование, которое было вам предъявлено, вам придется вручную указать, что, когда у вас есть ISomeService , вы возвращаете экземпляр SomeServiceImpl . Вы знаете, такие вещи, которые контейнеры объектов и фреймворки DI уже делают для вас. Так что вам, по сути, придется изобретать некоторые колеса. Кстати, Айенде писал в блоге о том, как можно создать пользовательский контейнер IoC в 15 строках кода, но, конечно, это не причина, по которой вы когда-либо должны делать что-либо подобное.
Люди, предъявляющие такие требования, должны предстать перед судом и быть приговорены к тому, чтобы никогда не подходить к разработке приложений. Введение такого требования иллюстрирует некоторое полное отсутствие знаний о передовой практике разработки приложений. Этих людей следует предупредить, прежде чем они нанесут дополнительный ущерб компании.
Так что просто объясните этим людям, что, изобретая колеса, есть 2 ошибки:
- вы потратите много времени на то, что уже было сделано кем-то другим
- вы будете допускать ошибки, поскольку не будете учитывать все крайние случаи, которые были приняты во внимание кем-то другим, разрабатывающим повторно используемую инфраструктуру DI.
В конце дня вы отправите свое приложение с опозданием по расписанию (поскольку вы бы потратили время на написание программного кода), и, что еще хуже, вы отправите приложение, которое будет содержать потенциальные ошибки.
Вывод: дорогой и глючный продукт. Ваше руководство, должно быть, действительно сошло с ума 🙂
Вывод2: используйте существующую инфраструктуру DI. Руководство даже не заметит, поскольку, похоже, они не понимают технических аспектов приложения, предъявляя такие требования.
Комментарии:
1. Я согласен с вашими соображениями, и я попытался объяснить эти проблемы (возможно, я плохо объяснил это), но есть опасение, что время, необходимое другим разработчикам для ознакомления с концепциями, не будет стоить того, и что может быть трудно нанять новых разработчиков, знакомых с конкретнымфреймворк.
2. @zaq, и вы думаете, что время, которое вы потратите на изобретение колес, внедряя пользовательский фреймворк DI, будет стоить того? Если разработчики не могут понять концепцию существующей инфраструктуры DI, прочитав миллионы учебных пособий, понимание концепции настраиваемой среды DI с настраиваемыми распознавателями зависимостей будет гораздо важнее, поверьте мне.
3. О, я не мог не согласиться, но, к сожалению, не меня нужно убеждать.
4. Я просто надеялся, что у кого-нибудь может быть идея о том, как это сделать, не создавая новые объекты служб непосредственно в контроллерах или не объявляя фабричные / одноэлементные методы во всех службах (без IOC).
5. @zaq, в своем ответе я предложил вам использовать инверсию управления и заставить конструкторы вашего контроллера использовать только интерфейс. Фактическое создание экземпляра конкретного типа будет выполнено в вашем пользовательском распознавателе зависимостей. Вы никогда не будете создавать какие-либо новые объекты службы непосредственно в своих контроллерах. Ваши контроллеры будут выглядеть точно так же, как если бы вы использовали платформу DI.
Ответ №2:
Прежде всего, я хотел бы спросить, почему руководство обязало вас не использовать шаблон и инструменты, которые позволили бы вам добиться слабой связи и внедрения зависимостей. Это то, о чем можно обсуждать и рассуждать?
С контейнером IoC тривиально реализовать an IControllerFactory , который разрешает контроллеры из контейнера и вводит необходимые службы.
В MVC 3 есть то IDependencyResolver , что вы могли бы использовать для достижения немного более слабой связи (через шаблон / анти-шаблон поиска служб), чем создание экземпляров сервисов непосредственно внутри контроллеров; этот интерфейс был разработан для использования с контейнером IoC, хотя на самом деле и был бы более плохой заменой сам по себе.
Комментарии:
1. Я изучил это и начал работать с ним, но, похоже, я просто закончу тем, что напишу свой собственный контейнер semi DI, что является плохой идеей. Я собираюсь согласиться с вашим предложением о «бедном человеке DI» из вашего комментария к моему первоначальному сообщению. Это все еще не очень хорошее решение, но я думаю, что это единственный вариант, учитывая мои ограничения. Спасибо за вашу помощь.
Ответ №3:
У вашего босса заостренные волосы? http://www.dilbert.com /
Вы могли бы сэкономить некоторое время, используя http://unitymvc3.codeplex.com / вместо того, чтобы писать свой собственный пользовательский распознаватель зависимостей. Его можно загрузить через Nuget http://nuget.org /. Если вы используете контейнер IOC, подобный этому, и используете внедрение конструктора, вы обнаружите, что ваши модульные тесты намного проще писать. Это предполагает, что ваш менеджер верит в модульное тестирование 😉 Удачи!
Комментарии:
1. Это выглядит довольно хорошо, но, к сожалению, я уже предложил Unity в качестве альтернативы Microsoft Spring.
2. Он очень прост в настройке и использовании (он специально разработан для использования Unity с MVC3), не требует какой-либо специальной настройки, а кривая обучения для членов вашей команды будет минимальной. Удачи, хотя, похоже, вам это может понадобиться 😉
3. Спасибо, Тони, может быть, я посмотрю на это и попробую еще раз.
Ответ №4:
руководство сообщило мне об этом весной.Net или любой другой контейнер IOC не должен использоваться в нашей среде.
Руководство говорит вам, что вам не разрешается писать слабо связанные, тестируемые и легко поддерживаемые приложения, вот что они вам говорят. Это странное ограничение.
Внедрение зависимостей — это передовая технология, которую многие разработчики не понимают. Однако руководство никогда этого не поймет, и это не их работа понимать это. Они могут диктовать тип технологии (например, .NET или Java), потому что это влияет на тип персонала, который им нужно нанять, но когда они начинают диктовать низкоуровневые детали реализации, которые мешают вам писать программное обеспечение для спуска, ваша компания движется к катастрофе.
Покиньте эту компанию сейчас, когда вы можете!
Другой вариант — использовать исходный код простого инжектора. Кодовая база достаточно мала (около 500 строк, просто используйте SimpleInjector.NET project), чтобы иметь возможность скопировать его в локальный проект (и лицензия разрешает это). Таким образом, это ваш собственный локальный контейнер DI, но полностью протестированный 🙂
Удачи.
Ответ №5:
Вам нужен новый дом. Существует множество организаций, которые ищут талантливых инженеров, заботящихся о качестве и масштабируемых архитектурах. Убедитесь, что вы нашли правильный, и они будут рады найти вас.
Избегайте соблазна спасти свою текущую команду от их собственной недальновидности. Из ваших описаний звучит так, будто вы уже пария, несмотря на ваши таланты. Примите тот факт, что вас не будут слушать.
Лучшая стратегия — притвориться заново рожденным командным игроком. Создайте свой проект MVC именно так, как просил ваш босс, то есть тупым способом, без разделения проблем. Когда версия 1 вашего проекта будет завершена и пройдет QA (если у вас есть какой-либо QA), ваш босс, вероятно, подумает, что он оправдан. Будьте готовы к такой реакции.
Лучшая надежда, которую вы возлагаете на просвещение своих нынешних членов команды, — это показать им, что даже если вы создаете программное обеспечение, используя те же самые глупые методы, которые им удобны, вы все равно можете запускать кольца вокруг них. Это может быть весело. Затем, когда вы уходите, вы даете им шанс подумать о возможности того, что вы были на что-то. Они могут либо воспользоваться этим шансом, либо выбрать постоянный комфорт, но это больше не будет вашей проблемой.