在工作中，我試圖在已有的大型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