Advantage数据访问层

Question

在工作中，我正在尝试在一个已经存在的大型PHP应用程序中实现n层模型。

我必须说服我的前辈，因为他们看不到额外的DA层的意义，因为性能。代码现在在业务逻辑中查询Db，并在从结果集中检索数据的同时在循环中进行计算。低性能成本。

我试着用显而易见的理由说服他们:透明性(“我们可以读SQL”)，数据库的改变(“不会发生”)。

他们的论点是，如果它是由一个单独的层完成的，这将意味着必须创建一个数据集，并在业务层中再次循环。成本计算性能。此外，创建这种n层模型将意味着大量的工作，这些工作没有“真正的”报酬。

这是一个性能问题，因此是拒绝单独的DA层的逻辑原因吗？

Answer 1

我认为你触及了一个重要的点:没有额外抽象层的手工优化SQL可能会更快。然而，这是有代价的。

问题可能是:额外速度的好处是否超过了数据库访问层的好处，例如封装SQL特定知识，以便工程师可以专注于业务逻辑(域层)。

在大多数情况下，您可能会发现，数据库抽象层的性能将足够好，只要实现是由这方面的专家完成的。如果处理得当，可以在很大程度上避免双缓冲区/循环。

我怀疑只有一小部分应用程序(我的猜测是不超过20%)的性能是如此关键，以至于抽象层不是一个选择。

但也有一种可能的混合解决方案:将抽象层用于80%的模块，其中灵活性和便利性优于速度，并在20%的模块中直接与数据库对话，其中速度至关重要。

我可能会投票支持抽象层，然后在需要的地方优化性能(这可能是通过直接与数据库对话以外的方法来实现的)。

Answer 2

与现有技术相比，数据访问层是过时的技术，因为它太过复杂和未经科学验证的技术，它在while循环中检查每个和sql数据类型并验证数据类型，.net面临着严重的应用程序域问题，比如从一个类文件执行代码到另一个类文件需要更多时间，因为.net程序集没有紧密耦合，证明了我的论点，我们可以在256MB内存中运行Suse linux，而不是windows 7或windows xp，而且.net声称自动内存管理，这不是真的，.net在堆中留下了大量未使用的内存。这会导致DAP架构的大量性能损失，而且与使用存储过程直接连接到数据库相比，DAL中的工作量要高出95%。不要使用DAL，而不是使用WCF或xml webservices