Dev*_*nTT 3 linq dependencies entity-framework inversion-of-control
我对依赖注入的经验不是很丰富，因此我非常重视您对以下方面的看法。
它（依赖注入/ IOC）在我公司的Web应用程序中使用。
我们公司目前的编程负责人讨厌这个应用程序，因为他不喜欢linq，实体框架和依赖项注入（应用程序中的所有功能）。他认为，所有这些因素共同导致了该应用的缓慢和脆弱。
他将造成性能下降的原因归咎于IOC容器，今天他说这句话“我不确定，但是它（IOC容器）必须使用反射，这非常糟糕”。
他还不喜欢使用接口（因为这会使查找在Visual Studio中实现接口的文件的定义更加困难），并将其用作bash IOC容器的另一个原因。
我最近发现了SOLID原理，并且上述观点并不适合我，因此我想知道经验丰富的开发人员的想法，以及是否有任何事实可以支持任何编程领导意见。
谢谢阅读。
我从未经历过因依赖项注入而导致的性能问题，因此我倾向于忽略这一点。
分离代码之间的依赖关系，尤其是分离诸如调用前端数据库之类的讨厌行为，这是毫无道理的。
但是，使用LINQ to SQL绝对会导致性能比SQL Server管理的存储过程中的代码差。
这必须与数据库中的代码问题相平衡。SQL是一种功能较弱的语言，由于无法使用动态SQL无法调用另一个存储过程，因此很难进行重构。另外，数据库中的代码可能不受源代码控制。由于数据库中的代码太多，我已经看到项目遭受了严重的损失。
就我个人而言，我将使用linq到sql，但不要担心将存储过程用于数据密集型操作或性能不佳的情况。
我要提防那些不喜欢特定技术但又不提出合理论据的人。人们往往更喜欢拥有最丰富经验的技术。
如果你不改变观点，这种讨论是赢不了的。
计算机不介意它们运行什么样的代码。可能他们甚至对我们称之为“意大利面条”的代码更“满意”，因为要遍历的访问路径更少。
但我们不为计算机编写代码。
所有这些架构指南，如 SOLID 原则，所有这些工具，如 IoC 容器或 ORM，所有这些第 3、4、5 代计算机语言都不是为计算机设计的，而是为我们软件开发人员设计的。
仅仅因为人类的大脑不是 CPU。
因此，我们需要所有这些工具来跟踪我们正在设计的内容并确保我们编写的内容可以转换为安全的运行时代码。把它推向极端，你的编程主管甚至不应该允许你用 C# 或 VB 编写，而是强迫你编写汇编代码。那么您将获得无与伦比的性能！（但更有可能是一堆运行时错误）。
正确的观点是谈论可维护的代码，因为代码总是在进化。而且经常有截止日期。不是计算机，但我们应该能够理解我们在做什么。我们将关注点分开是因为我们一次只能理解一个关注点。我们使用工具来生成 SQL，因为我们无法键入数百条 SQL 语句而不会出错，更不用说在数据库发生变化时在合理的时间内修改它们了。我们使用 IoC 容器是因为我们忘记了依赖关系或对象生命周期。
平衡实际上是性能与可维护代码。
一旦清楚这一点，就有了一个共同点，您可以从中进行性能测量。如果一个工具以轻微的性能下降为代价显着增加了上市时间，这可能是可以接受的。即使是用户也会明白这一点。
（我已经使这个问题比您直接提出的问题更广泛，msteel9999 的回答是准确的）。