-
樓主 / David007
- 時間: 2008-10-16 22:18這幾年俺主要做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? -
-
- 時間: 2008-10-16 22:24
-
-
第 3 樓 / 3M
- 時間: 2008-10-16 22:30
-
- 時間: 2008-10-16 23:05
David007 寫道:說明一下，Database Library 提供了大量的Method來存取數據。那位封裝Data Access的兄弟想簡化合並這些Method，於是帶來了bug和不靈活。
就像不應該重寫C++庫提供的函數一樣，以一己之力質疑和試圖“封裝”大型成熟商用SDK的作法似乎不太明智。
另外，微軟從MFC時代就開始將設計模式引入到SDK中，他們現在的產品肯定都是經過良好設計的。如果那位兄弟的設計水准沒有達到“I wrote the book”級別，最好不要重新設計他們的SDK。不過有一個例外情況：如果微軟的SDK對於你們的應用過於龐大和復雜，可以用Facade解決——不知道那位兄弟是不是出於這個目的和這樣設計的。 -
- 時間: 2008-10-16 23:14
-
- 時間: 2008-10-16 23:27
-
- 時間: 2008-10-16 23:38
-
- 時間: 2008-10-16 23:46
-
- 時間: 2008-10-17 09:12 David007 寫道:
直接寫sql效率是很高，可是很難維護。俺接觸到的兩個最長的stored procedure 都是700多行，真不知道那個作者是聰明呢還是糊塗。俺費了老鼻子勁抓住了n個蟲子，解了那個公司的燃眉之急，從此一舉奠定俺的地位
經驗就是：stored procedure裡的邏輯越少越好。
蟲子多不是pl/sql的問題，是developer的問題；pl/sql也一樣可以有好的設計；以前寫過或維護過最長的procedure有2,3000行的，在非常繁忙的CS系統中跑的好好的。
換個角度想，與其自己寫復雜的數據操作在logic裡還不如就用pl/sql來做，oracle裡有幾百個程序員在優化其內核，不用就浪費了 -
- 時間: 2008-10-17 11:00
討論：要不要創建Data Access layer
