DbEntry MVC 開(kāi)發(fā)小記

2019-11-17 03:56:04

字體：大中小

供稿：網(wǎng)友

　花了一周左右的時(shí)間，使用 DbEntry.Net 的 MVC 把我的網(wǎng)站重新設(shè)計(jì)了一下，同時(shí)也可以算是對(duì) DbEntry.Net MVC 的一次實(shí)用性測(cè)試及升級(jí)。在這里記錄一些感想。

　　DbEntry.Net MVC 更像 Ruby onRails，使用的腳手架方式也類(lèi)似，以前我就覺(jué)得，腳手架是挺重要的，在這次開(kāi)發(fā)中，也實(shí)際的感覺(jué)到腳手架的好處。事實(shí)上，直到現(xiàn)在網(wǎng)站已經(jīng)上線運(yùn)行，還有一些管理員功能是直接使用腳手架的。在敏捷開(kāi)發(fā)中，數(shù)據(jù)Model可能隨著開(kāi)發(fā)進(jìn)度的發(fā)展而發(fā)生變化，特別在開(kāi)發(fā)初期，很多不確定因素會(huì)導(dǎo)致Model的變化，所以一個(gè)好的腳手架模塊，應(yīng)該是能盡量延遲其被實(shí)體化的時(shí)間，一旦其被實(shí)體化，數(shù)據(jù)Model的變化，就很可能導(dǎo)致這些代碼的變化。所以，我覺(jué)得腳手架就不能是代碼生成器，即使代碼生成器可以作為“編譯前事件”而做到每次Model的變化都得到表現(xiàn)，卻很難判斷是否用戶(hù)修改過(guò)被生成的代碼，用戶(hù)修改過(guò)的代碼被覆蓋，會(huì)是一件很讓人喪氣的事。一般來(lái)說(shuō)，Controller的腳手架代碼不太需要修改，主要需要修改的是View，為了盡量增加腳手架View的生命周期，我為腳手架View增加了對(duì)于MasterPage的支持，雖然即使這樣，腳手架的View看起來(lái)還是有些簡(jiǎn)陋，不過(guò)，至少是和整體網(wǎng)站的風(fēng)格統(tǒng)一了，用戶(hù)也可以看到和使用MasterPage里的鏈接，可以盡量等到Model之類(lèi)的變量比較確定的時(shí)候，再加入定制的View。

　　以前在 javaeye 的一個(gè)帖子 ruby on rails為什么暫時(shí)無(wú)法成為企業(yè)應(yīng)用開(kāi)發(fā)的主流？里討論說(shuō) RoR 似乎鼓勵(lì)所有的代碼都寫(xiě)到一個(gè) controller 里，比如 javaeye 的 blog 就只有一個(gè)controller，我曾回貼說(shuō)可能 XP 開(kāi)發(fā)的話，是否只有一個(gè) controller 也無(wú)所謂，當(dāng)然，我現(xiàn)在也還是認(rèn)為 XP開(kāi)發(fā)的話，確實(shí)可以在很大程度上改善這種情況，不過(guò)，在這次開(kāi)發(fā)中，我卻覺(jué)得，是否所有功能都寫(xiě)在一個(gè) controller里，更多的是一個(gè)設(shè)計(jì)問(wèn)題。在開(kāi)始的一兩天里，我確實(shí)也把很多功能都放在了 ArticleController 里，article/rss,article/category 等也看起來(lái)挺順的，但是，它把 rss, category 的代碼混入了 article，而只要改變?yōu)閞ss/article 和 category/show，它的代碼就被放在了另外一個(gè) controller 里，而且，職責(zé)也更清晰，對(duì)RssController 來(lái)說(shuō)，支持 rss/comment 也更理所當(dāng)然了。

　　在這次網(wǎng)站的設(shè)計(jì)中，我第一次大量使用了 Static Page 方式。這是以前我為 DbEntry設(shè)計(jì)的一個(gè)用于分頁(yè)的算法，其源于使用搜索引擎的郁悶。很多時(shí)候，我們搜索一個(gè)東西，搜索引擎顯示其鏈接，等我們點(diǎn)擊進(jìn)去后，卻發(fā)現(xiàn)我們所在分頁(yè)根本就沒(méi)有我們要查的信息。原因在于，只要有新的文章不斷加入，常用的分頁(yè)算法對(duì)于特定文章的 PageIndex將會(huì)發(fā)生變化，比如最早的文章，將會(huì)隨著新文章的加入，而逐漸變?yōu)榈诙?yè)、第五頁(yè)、第二十八頁(yè)……。而解決這個(gè)問(wèn)題的方法，就是類(lèi)似動(dòng)態(tài)頁(yè)面靜態(tài)化的想法，最早的文章不應(yīng)該是80頁(yè)、90頁(yè)，而總應(yīng)該是第1頁(yè)，最新的文章才應(yīng)該是80頁(yè)、90頁(yè)。靜態(tài)分頁(yè)有一個(gè)問(wèn)題，就是包含最新記錄的頁(yè)面可能不到PageSize 那么大，如果顯示在首頁(yè)的位置，有時(shí)候會(huì)顯得比較單薄，所以，在這次開(kāi)發(fā)中，我增加了 Hybird方式，首頁(yè)使用傳統(tǒng)分頁(yè)，之后使用靜態(tài)分頁(yè)。

　　說(shuō)是網(wǎng)站重新設(shè)計(jì)，在于以前的數(shù)據(jù)庫(kù)結(jié)構(gòu)完全放棄了，在這次開(kāi)發(fā)中 Model完全由構(gòu)想的使用方式?jīng)Q定，而跟老的數(shù)據(jù)庫(kù)結(jié)構(gòu)關(guān)系不大，比如，老的數(shù)據(jù)庫(kù)結(jié)構(gòu)是固定兩層 Category，有 topic，有keyWord，而在新的數(shù)據(jù)庫(kù)結(jié)構(gòu)中，只有一層 Category，而把以前的第二層 Category 和 topic、keyword 都作為T(mén)ag 處理。這當(dāng)然導(dǎo)致數(shù)據(jù)庫(kù)遷移顯得比較麻煩，使用 DbEntry 的 BulkCopy，在一定程度上緩解了這個(gè)矛盾，對(duì)于 BulkCopy來(lái)說(shuō)，需要編寫(xiě)的是針對(duì)源數(shù)據(jù)庫(kù)的 SQL 語(yǔ)句，目標(biāo)數(shù)據(jù)庫(kù)的 SQL 語(yǔ)句是由 BulkCopy自動(dòng)根據(jù)目標(biāo)數(shù)據(jù)庫(kù)類(lèi)型生成的，所以我仍然可以使用一份代碼，從源數(shù)據(jù)庫(kù)生成 sqlite 數(shù)據(jù)庫(kù)用于開(kāi)發(fā)，生成 Firebird數(shù)據(jù)庫(kù)用于部署。不過(guò)，因?yàn)?Firebird 使用的是序列方式產(chǎn)生主鍵，而 BulkCopy 不涉及ORM，所以它不會(huì)去操作序列，雖然不需要像 Sql Server 插入主鍵那樣調(diào)用 SET IDENTITY_INSERTON，但是卻需要在導(dǎo)入數(shù)據(jù)后，重新設(shè)置序列，以便其能正確的產(chǎn)生主鍵，我使用的方法可能笨一點(diǎn)兒，就是用 max(id) 取得最大 id值，再多次調(diào)用 select 去取相關(guān)序列，反正速度挺快的，應(yīng)該也不需要多聰明的方法吧。不過(guò)也發(fā)現(xiàn)在 Firebird 上用ExecuteNonQuery 調(diào)用 select 取序列的話，根本不會(huì)執(zhí)行......

　　網(wǎng)站的 footer 上，寫(xiě)上 Powered By DbEntry.Net，感覺(jué)挺爽的，考慮稍微修改一下許可協(xié)議，如果有項(xiàng)目要使用 DbEntry.Net 的話，也要在經(jīng)常能見(jiàn)到的地方寫(xiě)上 Powered By DbEntry.Net :)

上一篇：《程序是給自己看的還是給別人看的》

下一篇：通過(guò)HttpWebRequest在后臺(tái)對(duì)WebService進(jìn)行調(diào)用