[David007]

這幾年俺主要做Business Logic layer，特痛恨做Presentation layer，因為受不了一天到晚把控件挪來挪去的痛苦。特高興把數據以xml格式送給做presentation的兄弟，看他痛苦

Business Logic總是要和database打交道的。俺主要是用Microsoft的Enterprise Library，感覺它的Database library 即滿足了一定的封裝性，又非常的靈活，比方說，不返回數據，返回一個標量，返回幾個數據，返回DataSet等等。

兩年前的一個項目中，一個兄弟覺得這不是個好的Design，生生做了一個Database layer，定義了一個Interface，每次調用數據庫之前先填充好Interface中的定義，然後再提交，由他的Database layer 調用Enterprise Libary。

於是俺們就有一個漂亮的設計：Presentation/Business Logic/Data Access/Database。可是調用數據庫不靈活，那位兄弟只好不斷改他的code。最後bug一堆，俺一直跟蹤到他的code裡面才發現問題。

後來俺發現，其實那個Data Access也不做什麼事情，直接就調用Microsoft的Database Library了。大量的工作是實現那個破數據接口 （Interface），搞的做Business Logic 的兄弟不爽。

俺想問問各位xdjm，用Enterprise Library裡的Database Library 是不是已經足夠了，還是各位都創建自己的Database Access Layer?

[David007]

說明一下，Database Library 提供了大量的Method來存取數據。那位封裝Data Access的兄弟想簡化合並這些Method，於是帶來了bug和不靈活。

[3M]

似乎多余

[SARS]

David007 寫道:

說明一下，Database Library 提供了大量的Method來存取數據。那位封裝Data Access的兄弟想簡化合並這些Method，於是帶來了bug和不靈活。

就像不應該重寫C++庫提供的函數一樣，以一己之力質疑和試圖“封裝”大型成熟商用SDK的作法似乎不太明智。

另外，微軟從MFC時代就開始將設計模式引入到SDK中，他們現在的產品肯定都是經過良好設計的。如果那位兄弟的設計水准沒有達到“I wrote the book”級別，最好不要重新設計他們的SDK。不過有一個例外情況：如果微軟的SDK對於你們的應用過於龐大和復雜，可以用Facade解決——不知道那位兄弟是不是出於這個目的和這樣設計的。

[小丹尼]

自己寫DAO不是很流行了吧

現在不是流行hibernate這樣技術了？

所以，要麼自己寫sql。改什麼就改sql

要麼用hibernate, data library這樣的技術，省心點算了。

隨便一說

[roxer]

小系統自己寫DAO還行，方便不用設一堆東西，大中型系統還是用hiebernate，top-link之類的JPA成型的東西，省很多事；要不搞幾台高性能數據庫服務器，直接寫sql，其實性能上也差不了太遠

[David007]

小丹尼 寫道:

自己寫DAO不是很流行了吧 現在不是流行hibernate這樣技術了？ 所以，要麼自己寫sql。改什麼就改sql 要麼用hibernate, data library這樣的技術，省心點算了。 隨便一說

同意。不過我一般盡可能不把邏輯寫道stored procedure裡去，因為SQL難維護。

我的stored procedure盡可能只做insert/update/delete，邏輯搬到Business Layer裡去

[David007]

roxer 寫道:

小系統自己寫DAO還行，方便不用設一堆東西，大中型系統還是用hiebernate，top-link之類的JPA成型的東西，省很多事；要不搞幾台高性能數據庫服務器，直接寫sql，其實性能上也差不了太遠

直接寫sql效率是很高，可是很難維護。俺接觸到的兩個最長的stored procedure 都是700多行，真不知道那個作者是聰明呢還是糊塗。俺費了老鼻子勁抓住了n個蟲子，解了那個公司的燃眉之急，從此一舉奠定俺的地位

經驗就是：stored procedure裡的邏輯越少越好。

[roxer]

David007 寫道:

roxer 寫道: 小系統自己寫DAO還行，方便不用設一堆東西，大中型系統還是用hiebernate，top-link之類的JPA成型的東西，省很多事；要不搞幾台高性能數據庫服務器，直接寫sql，其實性能上也差不了太遠 直接寫sql效率是很高，可是很難維護。俺接觸到的兩個最長的stored procedure 都是700多行，真不知道那個作者是聰明呢還是糊塗。俺費了老鼻子勁抓住了n個蟲子，解了那個公司的燃眉之急，從此一舉奠定俺的地位 經驗就是：stored procedure裡的邏輯越少越好。

蟲子多不是pl/sql的問題，是developer的問題；pl/sql也一樣可以有好的設計；以前寫過或維護過最長的procedure有2,3000行的，在非常繁忙的CS系統中跑的好好的。

換個角度想，與其自己寫復雜的數據操作在logic裡還不如就用pl/sql來做，oracle裡有幾百個程序員在優化其內核，不用就浪費了

[David007]

再補充說明一下，數據存取層不是DAO，實際上數據存取層就是調用ADO.NET 來存取數據。

在一個大型的系統中，用C#的Interface定義數據層接口，使得接口統一化，好處是有的，只是覺得受限制。