在工作中，我试图在一个已经存在的大型 PHP 应用程序中实现 n 层模型。
我必须说服我的前辈，因为他们看不到额外的 DA 层的意义，因为性能。代码现在在业务逻辑中查询 Db，并在从结果集中检索数据的同时在循环中进行计算。性能成本低。
我已经尝试通过显而易见的原因说服他们：透明度（'我们可以读取 SQL'）、更改数据库（'不会发生'）。
他们的论点是，如果由单独的层完成，则意味着必须创建数据集，并在业务层中再次循环。成本计算性能。 此外，创建这种 n 层模型将意味着大量没有“实际”报酬的工作。
这是一个性能问题，因此有理由拒绝单独的 DA 层吗？
【问题讨论】：
我认为您触及了一个重要点：没有额外抽象层的手动优化 SQL 可以更快。然而，这是有代价的。
问题可能是：额外速度的好处是否超过数据库访问层的好处？封装 SQL 特定知识，让工程师可以专注于业务逻辑（领域层）。
在大多数情况下，您可能会发现数据库抽象层的性能已经足够好，只要由这方面的专家完成。如果处理得当，可以在很大程度上避免双缓冲/循环。
我怀疑只有一小部分应用程序（我的猜测不超过 20%）对性能至关重要，以至于抽象层不是一个选项。
但也有一种可能的混合解决方案：将抽象层用于 80% 的模块，在这些模块中灵活性和便利性胜过速度，并在 20% 的模块中直接与数据库对话，其中速度至关重要。
我可能会投票支持抽象层，然后在需要时优化性能（这可以通过直接与数据库对话以外的方式来实现）。
【讨论】：
与现有技术相比，数据访问层是过时的技术，因为它过于复杂且未经科学验证的技术，它会在一段时间循环中检查每个和 sql 数据类型并验证数据类型，.net 面临着严重的应用程序域问题，例如执行从一个类文件到另一个类文件的代码需要更多时间，因为.net 程序集不是紧密耦合的，证明我的论点我们可以以非常流畅的方式在 256 MB Ram 中运行 Suse linux，但不是 windows 7 或 windows xp，而且.net 声称自动内存管理，但实际上并非如此，.net 在堆中留下了大量未使用的内存，这导致 DAP 架构中的大量性能损失，而且 DAL 的工作量比直接连接到使用存储过程的数据库，不要使用 DAL，而是使用 WCF 或 xml webservices
【讨论】：