在工作中，我正在尝试在现有的大型PHP应用程序中实现n层模型。
我必须说服我的老年人，因为他们没有看到额外的DA层，因为性能。代码现在在业务逻辑中查询Db，并在从结果集中检索数据时在循环中计算。性能低。
我试图通过显而易见的原因说服他们：透明度（'我们可以阅读SQL'），更改数据库（'不会发生'）。
他们的论点是，如果它是由一个单独的层完成的，那就意味着必须创建一个数据集，并在业务层中再次循环。成本效益。 此外，创建这种n层模型意味着许多工作没有“真正的”工资。
这是一个性能问题，因此合理的理由是对单独的DA层说不？
答案 0 :(得分：3)
我认为你触及了一个重点：手工优化的SQL没有额外的抽象层可以更快。然而，这是有代价的。
问题可能是：额外速度的好处是否超过数据库访问层的好处，例如：封装SQL特定知识，以便工程师可以专注于业务逻辑（域层）。
在大多数情况下，您可能会发现数据库抽象层的性能足够好，前提是实现是由专家完成的。如果正确完成，可以在很大程度上避免双缓冲/循环。
我怀疑只有一小部分应用程序（我的猜测不超过20％），其中性能如此关键，以至于抽象层不是一个选项。
但也有可能的混合解决方案：80％的模块使用抽象层，灵活性和便利性超过速度，并在速度至关重要的20％模块中直接与数据库对话。
我可能会投票支持抽象层，然后根据需要优化性能（可以通过除直接与数据库交谈之外的方式实现）。
答案 1 :(得分：1)
与现有技术相比，数据访问层是过时的技术，因为它太复杂了。科学上未经证实的技术，它检查while循环中的每个和sql数据类型＆amp;验证数据类型，.net面临严重的应用程序域问题，如从一个类文件执行代码到另一个类文件需要更多时间，因为.net程序集没有紧密耦合，证明我的参数我们可以在256 MB Ram中运行Suse linux一个非常流畅的方式，但不是Windows 7或Windows XP，而且.net声称自动记忆管理，事实上并非如此，.net在堆中留下了大量未使用的内存，这导致DAP架构中的大量性能损失，此外，与使用存储过程直接连接到数据库相比，DAL的工作量增加了95％，不要使用DAL，而不是使用WCF或xml webservices