在工作中，我试图在已有的大型PHP应用程序中实现n层模型。优势数据访问层
我必须说服我的老人，因为他们没有看到额外的DA层，因为性能。代码现在在业务逻辑中查询Db，并在循环中计算结果集中的数据。低性能成本。
我试图说服他们的原因很明显：透明度（'我们可以读取SQL'），更改数据库（'不会发生'）。
他们的观点是，如果它是由一个单独的层完成的，这将意味着必须创建一个数据集并在业务层再次循环。成本核算表现。 另外，创建这个n层模型将意味着很多没有“实际”支付的工作。
这是一个性能问题，因此是一个合理的理由对不同的DA层说不？
我觉得你触及一个重要的观点：没有额外抽象层的手优化SQL可以更快。然而，这是一个代价。
这个问题可能是：附加速度的好处是否超过了数据库访问层的好处，例如封装SQL特定的知识，以便工程师可以专注于业务逻辑（领域层）。
在大多数情况下，您可能会发现数据库抽象层的性能足够好，前提是由专家在此问题上完成实现。如果做得好，双缓冲/循环可以在很大程度上避免。
我怀疑只有一小部分应用程序（我的猜测不超过20％）在性能如此重要以至抽象层不是一个选项。
但也有混合解决方案可能：对80％的模块使用抽象层，其中灵活性和便利性胜过速度，并在速度至关重要的20％模块中直接与数据库交谈。
我可能会投票赞成抽象层，然后根据需要优化性能（这可以通过除直接与数据库直接交流的方式来实现）。
数据访问层是过时的技术比较本技术，因为实在是太复杂&未经科学证实的技术，它checkes每个和SQL数据类型在一个while循环&验证数据类型，.NET面临严峻的应用程序域之类的问题执行代码从一个类文件到另一个类文件花费更多的时间，因为.net程序集不紧密耦合，证明我的论点，我们可以以非常平滑的方式运行Suse linux 256 MB RAM，但不是Windows 7或Windows XP，而且.net声称自动记忆管理，事实上并不是这样，.net在堆中留下了大量未使用的内存，这导致DAP架构中大量的性能损失，而且DAL的努力比直接连接数据库使用存储过程，不要使用DAL，而不是它使用WCF或xml webservices
妥协似乎要走的路。谢谢。 – eddy147 2010-08-16 14:46:05