2015-01-20 3 views
1

Мы создаем веб-приложение ASP.NET MVC 5. Мы можем использовать с помощью контейнера IoC для разрешения зависимости службы, но все же новые/невежественные разработчики могут создавать экземпляр классов обслуживания, пока они им нужны, а не разрешать их с использованием инфраструктуры DI.Как заставить стиль DI

Есть ли способ (конфигурации правил кода в Visual Studio) или инструмента остановить (давая предупреждение или сообщение об ошибке) разработчиков использовать «новое» ключевое слово, чтобы создать экземпляр класса обслуживания. Спасибо.

+2

Это, кажется, как-то пагубная цели для меня. Для этого вам придется научить ваших «новых/невежественных» разработчиков использовать этот инструмент для проверки качества своего кода. или, возможно, вы можете заставить его автоматически проверять код, когда они его совершают? Не было бы лучше научить ваших разработчиков использовать IoC вместо этого и предоставить им причину и мотивацию сделать это? – Kjartan

+0

Я понимаю вашу точку зрения ... но я думаю, что лучше иметь систему проверки дурака. Далее я верю в Альберта Эйнштейна, когда он сказал: «Две вещи бесконечны: Вселенная и глупость человека» (включая меня). –

+0

Вы используете Resharper? Если это так, вы можете настроить его для предупреждения об этом. –

ответ

2

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

Пример: https://www.jetbrains.com/resharper/webhelp80/Reference__Add_Edit_Highlighting_Pattern.html

Я предположил бы, что вам нужно определить типы, которые вы хотите внедрить, а затем добавить их в свой шаблон.

+0

Это интересно. Не могли бы вы привести пример пользовательского шаблона, который может быть полезен для OP в этом контексте? – Steven

+0

Я думаю, что это легче сказать, чем сделать (хотя я совершенно не знаком с этой функцией R #). Как правило, вы хотите проверить, что «определенные типы классов» не являются ссылочными как одиночные, но вводятся в конструктор с использованием их интерфейсов. Вопрос действительно в том, как определить эти «определенные типы классов» и как обнаружить, что они являются ссылками и создаются непосредственно, вместо того, чтобы вводить их через интерфейс. Я не уверен, что шаблоны шаблонов достаточно гибки, чтобы сделать такой глубокий анализ. – Steven

+1

Я думаю, вы, вероятно, правы, @Steven. Тем не менее, это пища для размышлений ... –

3

Вы не можете навязать это при использовании инструментами разработчиков. Они всегда найдут способы обойти ваши «глупые» инструменты. Вместо этого вы должны привести пример, научить их, обучать их. Просмотрите ли коды и объясните, почему то, что вы предлагаете, - это путь.

+0

Очевидно, мы должны учить и обучать удивительности. Но иногда бывает глупая ошибка. Поэтому, чтобы избежать этих ... Есть ли способ показать хотя бы предупреждение с использованием или без использования сторонних инструментов в Visual Studio? –

+0

@PraveenPrajapati: Всегда помните, чтобы предпочесть [Физические лица и взаимодействия над процессами и инструментами] (http://www.agilemanifesto.org/). Если вы не можете заставить команду соответствовать, инструменты не помогут. И поскольку ваше требование, похоже, особенно «без рутинных партийных инструментов», единственное решение: делать обзоры кода. – Steven

+0

Конечно ... согласен с вами :-) и хорошо иметь инструменты ... (в противном случае почему так много инструментов есть и рекомендовано для мастера?) –

1

Если у вас есть наивные/неосведомленные разработчики, в ваш проект будет входить плохой код. Вы должны изменить свой процесс, чтобы проверки кода требовались до того, как этот плохой код внесет его в ваш репозиторий.

Обратите внимание, что «невежественные» здесь не означают глупых или плохих разработчиков. Это просто означает, что люди, которые не знают, что есть лучший способ сделать что-то. Как только вы научите их лучшему пути, и они узнают, что от них ожидается, это подорвет их невежество.

Что вы можете сделать:

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

  2. Поместите свои интерфейсы в одно пространство имен и реализации служб под другим пространством имен. При просмотре, сканировании файлов для пространства имен служб, и если он используется везде, где он не предполагается использовать, отклоните запрос на pull.

  3. Всякий раз, когда вы замечаете, что нарушение правила, которое вы хотите применить, переместилось в ваш репозиторий, запустите BLAME, чтобы выяснить, какой разработчик представил плохой код. Поговорите с этим человеком. Узнайте, почему они сделали это так, а не так, как вы предпочитаете. Покажите им, почему предпочтительнее делать это по-своему.

  4. Имейте модульные тесты для вашего кода. Иногда бывает сложно сделать тесты, когда реализации служб жестко закодированы в методе-под-тестированием, а не издевательствовать над интерфейсом службы.

Мне нравится @David Osborne's R# idea, но разработчики всегда могут приостановить R #, или отключить его вообще. В конечном итоге это проблема процесса. I agree with @Steven, что вы должны привести пример, научить и тренировать. Постройте свою команду, поделившись своими знаниями, не тащите их, наказывая их за неправильное выполнение.

Смежные вопросы