三層的困惑

2021-09-05 19:04:37 字數 851 閱讀 2569

這個問題困惑我已經很久了,從開始學習。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...

三層 我眼中的三層結構

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

成也三層,敗也三層

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