Внедрение зависимостей и сопровождение кода - PullRequest
8 голосов
/ 30 октября 2010

Я работаю над проектом (vb.net/asp.net), который использует интерфейсы для обеспечения внедрения зависимостей. Но мне кажется, что ремонтопригодность кода была убита. Когда я хочу прочитать код, я не могу просто перейти к коду связанного класса, который используется. Все, что я вижу, это интерфейсы, и поэтому мне приходится искать в проекте, чтобы выяснить, какие классы делают реализацию. Это действительно вредит моей производительности.

Да, я знаю, что теперь я могу реализовать интерфейсы с большим количеством классов замещения. Но, например, я знаю, что не буду менять свой источник данных в ближайшее время - мне не нужно включать возможность обменивать это. Все эти внедрения зависимостей кажутся мне излишними (на самом деле, единственная реальная причина, по которой это происходит, - это поддержка фиктивных классов для модульного тестирования). Я на самом деле читал несколько мест, где состояние DI на самом деле лучше для удобства обслуживания. Но это предполагает, что вы уже знаете, где все находится, и знаете, какой класс вам нужно обновить. Узнать, где искать, это та часть, которая убивает меня.

Итак, мой вопрос: есть ли лучший способ пройти через код? Есть ли лучший способ сделать код более понятным? Мы просто делаем это неправильно? Или это для курса?

Ответы [ 2 ]

5 голосов
/ 30 октября 2010

Определенно есть некоторые издержки для DI, особенно когда ваша конфигурация отделена от вашего кода.Хотя этот равен для курса, с ним легче справляться со временем, и по мере лучшего понимания кода.

Тем не менее, равен инструменты, которые могут помочь - взгляните на Resharper или CodeRush .Оба предлагают отличные улучшения для навигации по коду в Visual Studio.Resharper имеет превосходные «Перейти к символу» или «Перейти к реализации» методы, которые быстро помогут вам перейти к реализации вашего интерфейса, где бы он ни находился.

Что касается удобства обслуживания: в общем, слабосвязанная конструкция становится более важной с течением времени, потому что изменится .Чем более тесно связан ваш код, тем сложнее вносить небольшие изменения, не влияя на общее приложение.Здесь очень важна зависимость от интерфейсов - независимо от того, выберете ли вы Dependency Injection .

4 голосов
/ 01 ноября 2010

Ремонтопригодность - это много разных вещей.В целом, это касается степени, в которой вы можете продолжать развивать приложение , добавляя новые функции.

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

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

Хотя это не серебряная пуля.Слабая связь - обязательное условие для поддерживаемого кода, а не гарантия.

...