Зависимость, вызывающая низкую производительность (ASP.NET MVC)

Question

Я не очень опытен с инъекцией зависимостей, поэтому я очень ценю ваше мнение о следующем.

Это (инъекция зависимости/IOC) использовалось в веб-приложении в моей компании.

Текущее руководство по программированию в нашей компании ненавидит это приложение, так как ему не нравится linq, инфраструктура сущности и инъекция зависимостей (все, что входит в приложение). Он считает, что все вместе они способствуют тому, чтобы приложение было медленным и хрупким.

Он обвиняет контейнер МОК в большинстве случаев для воспринимаемой низкой производительности, и сегодня сказал слова об этом: «Я не уверен, но он (контейнер МОК) должен использовать отражение, что очень плохо».

Он также не приветствует использование интерфейсов (поскольку он позволяет найти определение файла, который затрудняет интерфейс в Visual Studio), и использует это как еще одну причину для контейнеров IOS в bash.

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

Спасибо за чтение.

Answer 1

Я никогда не испытывал проблем с производительностью, вызванных инъекцией зависимостей, и я хотел бы проигнорировать это.

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

Однако использование LINQ to SQL может привести к снижению производительности по сравнению с кодом в хранимой процедуре, управляемой SQL Server.

Это должно быть сбалансировано с проблемой кода в вашей базе данных. SQL является менее мощным языком, его трудно реорганизовать, поскольку вы не можете вызвать другую хранимую процедуру без использования динамического SQL. Также код в вашей базе данных может не находиться под контролем источника. Я видел, что проекты страдают плохо, так как в базе данных слишком много кода.

Лично я хотел бы использовать linq для sql, но не бойтесь использовать хранимую процедуру для работы с интенсивной работой или плохо выполняющей функции.

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

Answer 2

Это тип обсуждения, которого вы не можете выиграть, если вы не измените перспективу.

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

Но мы не пишем код для компьютеров.

Всех эти архитектурные принципы, как Твердые принципы, все эти инструменты, такие как контейнеры IoC или ORMs, все эти 3rd-, 4th-, компьютерные языки пятого поколения были не предназначены для компьютеров, но для нас, разработчиков программного обеспечения.

Просто потому, что человеческий разум не является ЦП.

Поэтому нам нужны все эти инструменты, чтобы отслеживать, что мы разрабатываем, и гарантировать, что то, что мы пишем, можно преобразовать в безопасный код времени выполнения. Принимая это в крайности, ваш вывод на программирование не должен даже позволить вам наслаждаться письмом на C# или VB, но заставлять вас писать код ассемблера. Тогда вы получите непревзойденную производительность! (Но, скорее всего, это ошибка от ошибок во время выполнения).

Правильная перспектива состоит в том, чтобы говорить о код поддерживаемого кода, потому что код всегда развивается. И часто бывают крайние сроки. Не компьютер, но мы должны быть в состоянии понять, что делаем. Мы разделяем озабоченность, потому что мы можем понимать только одну проблему одновременно. Мы используем инструменты для генерации SQL, потому что мы не можем вводить сотни операторов SQL без ошибок, не говоря уже о том, чтобы модифицировать их в разумные сроки, если база данных изменится. Мы используем контейнеры IoC, потому что забываем о зависимостях или жизненных циклах объектов.

Баланс действительно Производительность против ремонтопригодного кода.

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

---

(я сделал это немного шире, чем ваш немедленном вопрос, ответ msteel9999 является спот-).