三層的困惑

這個問題困惑我已經很久了，從開始學習。net到現在……

寫三層的時候，遇到這樣的情況怎麼辦？

user

article

//用於儲存最後顯示於表示層的資料，相當於fascade。這是頁面上用於繫結在repeater等控制項上的最終資料

datatable dt = new datatable();dt.addcolumn("articletitle");

dt.addcolumn("username");

//通過bll物件獲取全部文章物件

list articles = someclass.getallarticles();

//每個文章物件，

foreach(article a in articles)

//顯示在頁面上

repeater1.datasource = dt;

repeater1.databind();

在這裡，打星的地方查了n多次資料庫，這當然不行，效能很差。

方案一：直接用sql語句構造乙個鏈結的字串，如：select articles.title,user.username from articles inner join user on ....

然後再查詢。

問題：這樣的話，怎麼樣做到「三層」呢？在bll，又應該返回哪個物件的集合呢？

方案二：在資料庫裡使用檢視，對應檢視在model中構造對應的model.

問題：這樣的話，如果表示層改變乙個要顯示的字段，不就要新建立乙個檢視，並建立相應的model?

方案三：有人說使用型別化的dataset，不過這個方案一聽就不太喜歡。畢竟想用物件的方式訪問資料嘛。

暫時把問題記在這裡，何時能解決了，再說吧～

三層的困惑

這個問題困惑我已經很久了，從開始學習。net到現在 寫三層的時候，遇到這樣的情況怎麼辦？user article 用於儲存最後顯示於表示層的資料，相當於fascade。這是頁面上用於繫結在repeater等控制項上的最終資料 datatable dt new datatable dt.addcolu...

三層 我眼中的三層結構

從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...

成也三層，敗也三層

這重構版的機房的計畫早就開始，但開始的僅僅是計畫，卻遲遲沒有行動的意思，於是頻頻地徘徊著，迷茫著。這都過去三個星期了，每次的停滯不前我都有自己的理由，但是我應該從心底裡明白 成也三層，敗也三層 用三層對機房收費進行重構是乙個坎兒，這就是乙個對我們的的考驗，挺過去的就是通往下一站的乘客，沒過去應該就和...