b2c 商城項(xiàng)目經(jīng)驗(yàn)總結(jié)

時(shí)間：2023-03-28 21:26:01 | 來源：電子商務(wù)

時(shí)間：2023-03-28 21:26:01 來源：電子商務(wù)

提示：本文約三千字。

經(jīng)過三個(gè)月時(shí)間，終于完成了我的第二個(gè)項(xiàng)目，先簡要概括下，該項(xiàng)目是個(gè)“b2c”的商城，b2c 指唯品會、小米商城這種商家-客戶的模式，像京東、淘寶這種做平臺的叫 C2C（我猜這個(gè) 2 可能是取的 to 和 two 的諧音？），C2C 目前已被京東、淘寶、拼多多占據(jù)了絕大部分市場份額，所以做 C2C 意義不大，而且 C2C 的復(fù)雜度要遠(yuǎn)超 b2c，不適合我個(gè)人來做。項(xiàng)目的前端樣式主要仿照小米商城，當(dāng)然只是仿照了其樣式，內(nèi)部邏輯應(yīng)該是完全不同的，后臺管理系統(tǒng)的樣式很常見，主要參考了這個(gè)開源項(xiàng)目：https://gitee.com/hnjihai/jshop_mall

其實(shí)該項(xiàng)目做到一半時(shí)，我發(fā)現(xiàn)“商城”并不適合作為個(gè)人項(xiàng)目來開發(fā)，因?yàn)樗暮诵氖巧唐?，而商品這個(gè)東西通常要包含很多素材，而收集這些素材是屬于程序之外的事情，弄這些素材真的很麻煩，我是從小米商城上扒的資源，再添加到我自己的數(shù)據(jù)庫中，過程花費(fèi)了我四五天時(shí)間，當(dāng)時(shí)我就想，如果是做個(gè)“論壇”就不會有這個(gè)麻煩。

上次提到，寫項(xiàng)目主要是難在設(shè)計(jì)“系統(tǒng)模型”這種宏觀層面上的東西，這次項(xiàng)目更加深了我的這個(gè)觀點(diǎn)。一般來說，“系統(tǒng)模型”既要能靈活適應(yīng)“需求”的不斷變化，同時(shí)也要能很好的滿足當(dāng)前需求，光做到這點(diǎn)就很難，起碼對我來說很難，比如這次我埋頭設(shè)計(jì)了十天的模型，到最后還是漏洞百出，別說滿足變化的“需求”了，即使是當(dāng)前需求都滿足的很勉強(qiáng)，當(dāng)然很大程度上是因?yàn)槲以谶@方面本身就缺乏經(jīng)驗(yàn)，算上上次的新聞?wù)?，這也只是我第二次設(shè)計(jì)一個(gè)項(xiàng)目，而且這次的 b2c 商城在規(guī)模上要比上次的新聞?wù)痉撕脦妆?，?nèi)部邏輯也有很大不同，所以我確實(shí)是缺乏經(jīng)驗(yàn)。但就問題本身來說，我還是覺得相當(dāng)有難度，你得考慮的非常非常全面，稍不注意就會出現(xiàn)紕漏，要知道這個(gè)“考慮”是建立在你還沒做的基礎(chǔ)上的，你需要在沒做時(shí)就考慮到整個(gè)項(xiàng)目的方方面面、邊邊角角，即要想到“該有什么”，又要想到“該如何組合、協(xié)調(diào)”它們，還要想到“某個(gè)部位具體的技術(shù)細(xì)節(jié)”，甚至想到如果以后要加入一些東西，該在哪里預(yù)留位置？寫項(xiàng)目就是要解決這個(gè)大而復(fù)雜的問題，它的局部難度往往不高，甚至很簡單，但是要想把它的整體做好，就很難，非常難。

基于上次做項(xiàng)目的經(jīng)驗(yàn)，這次我是本著先設(shè)計(jì)，再實(shí)現(xiàn)的原則做的，其實(shí)想想寫程序都是這么回事，把你腦海中想的東西用編程語言精確的表達(dá)出來，如果你腦海中沒東西，那自然也無從寫起，或者寫出來一坨屎。我首先花了十天時(shí)間進(jìn)行抽象層的設(shè)計(jì)，這十天也包括查相關(guān)信息，因?yàn)槲覄傞_始對如何實(shí)現(xiàn)一個(gè)商城是一無所知的，甚至不知道 b2c 和 c2c 是啥，我設(shè)計(jì)抽象層的步驟主要分確定需求、設(shè)計(jì)業(yè)務(wù)流程、設(shè)計(jì)數(shù)據(jù)庫、設(shè)計(jì)權(quán)限系統(tǒng)這四步，具體過程的話，主要還是參照現(xiàn)有的商城，比如淘寶、小米商城這些，思考下我寫的商城該有什么功能，這樣需求就確定下來了，接著業(yè)務(wù)邏輯也一樣，然后是數(shù)據(jù)庫，數(shù)據(jù)庫是個(gè)重頭戲，要思考該用什么樣的內(nèi)部邏輯來管理這些數(shù)據(jù)，怎樣設(shè)計(jì)才能更便于實(shí)現(xiàn)需求，這也是個(gè)很棘手的事情，我十天時(shí)間主要就花在設(shè)計(jì)它上了，那時(shí)候整天開著 xmind 不停畫腦圖，不停的改來改去，最后實(shí)在改不動了才慢慢確定下來。

雖然這次項(xiàng)目我遵循了上次總結(jié)出的原則，先設(shè)計(jì)，再實(shí)現(xiàn)，實(shí)現(xiàn)時(shí)先做基本框架，然后層層遞進(jìn)，不過現(xiàn)在我覺得這樣也不對，因?yàn)檫@樣做時(shí)，前期設(shè)計(jì)時(shí)是完全依靠想象來進(jìn)行的，沒有先寫哪怕一點(diǎn)代碼，這就造成很多局部的設(shè)計(jì)與實(shí)際情況很不貼切，甚至存在很多遺漏，導(dǎo)致在設(shè)計(jì)模型時(shí)不能充分考慮到需求的細(xì)節(jié)，比如這次項(xiàng)目中的首頁輪播圖、商品類展示推薦圖、展示到首頁的商品類，以及后來的優(yōu)惠券、退貨、售后等模塊，它們要么是沒有被集成到后臺管理界面上，要么是由于數(shù)據(jù)庫設(shè)計(jì)缺陷導(dǎo)致幾乎做不出來，沒集成到頁面上的就需要在源碼里臨時(shí)添加，很麻煩，而屬于數(shù)據(jù)庫缺陷的就只能砍掉，除非對整個(gè)項(xiàng)目進(jìn)行大規(guī)模改動。經(jīng)過思考總結(jié)后，我發(fā)現(xiàn)讓前期設(shè)計(jì)與前端頁面編寫同步進(jìn)行才是更好的選擇，因?yàn)橹痪帉戫撁婺０娌⒉恍枰嗌贁?shù)據(jù)支撐，想改也是很快的，而頁面模板卻能比較具體的反映出實(shí)際需求到底有哪些，這對前期設(shè)計(jì)的幫助我覺得是很大的，這點(diǎn)我這樣直接說，沒做過項(xiàng)目的同學(xué)可能不是很好理解，這里我只能建議你先做一個(gè)項(xiàng)目感受一下。

接下來是技術(shù)方面，項(xiàng)目應(yīng)用到的技術(shù)是 Sass、JQuery、ThinkPhp，起初我還打算用 Bootstrap，但正式開工后我發(fā)現(xiàn)它非常難用，Bootstrap 會私自加很多全局樣式，導(dǎo)致樣式混亂，可以說就是個(gè)攪屎棍，所以我便棄用了。項(xiàng)目生成視圖的方式主要仍然是字符串拼接，沒怎么用到 tp 的模板引擎，只是將頁面主體結(jié)構(gòu)用 tp 的模版引擎 fetch() 出來，之后再在前端發(fā) ajax 請求過來，后臺把頁面各個(gè)局部位置的 html 拼接后再發(fā)送過去。我不用模版引擎主要是因?yàn)橄埠脝栴}，而且如今通過虛擬 DOM 在前端進(jìn)行渲染的方式已經(jīng)越來越流行了，虛擬 DOM 實(shí)現(xiàn)了徹底的前后端分離，所以我覺得自己沒有必要非去使用模板引擎，我在學(xué)習(xí)時(shí)也跳過了 tp5 的模板語法。代碼方面，秉承我的一貫作風(fēng)，整個(gè)項(xiàng)目沒有套用任何現(xiàn)成模版，前后端都是我自己一點(diǎn)點(diǎn)寫出來的，引用的插件共兩個(gè)，一個(gè)美化滾動條，另一個(gè)是 eCharts，剩下的大概有十幾個(gè)效果，以及常用函數(shù)都是我自己動手封裝實(shí)現(xiàn)的，目前還沒整理，初步估計(jì)應(yīng)該能整理出個(gè)一千多行吧。

代碼編寫上，我踩了個(gè)比較大的坑，由于對 MVC 不熟悉（畢竟用框架做項(xiàng)目我還是第一次），我對在什么情況下使用 model 沒什么概念，起初我一味的在控制器中使用 Db，因?yàn)橹岸际怯妹嫦蜻^程的方式寫原生 php，業(yè)務(wù)邏輯都是直接調(diào) PDO 操作數(shù)據(jù)庫，所以即便學(xué)了 tp5，也只是知道有 model 這么個(gè)東西，但并不知道具體是在什么情況下去使用它，所以我起初寫項(xiàng)目時(shí)一直在用 Db 類，然而寫了大概半個(gè)月后我發(fā)現(xiàn)自己經(jīng)常要用到 cv 大法（復(fù)制粘貼），因?yàn)槲医?jīng)常需要在不同的控制器內(nèi)對同一數(shù)據(jù)表中取出的數(shù)據(jù)進(jìn)行相同的操作，我意識到這會造成大量的代碼冗余，代碼冗余的缺點(diǎn)顯而易見 —— 維護(hù)性差、可讀性差、難以迭代，要解決這個(gè)問題，只有多進(jìn)行一些封裝，但用函數(shù)封裝顯然不是個(gè)好辦法，不同數(shù)據(jù)表進(jìn)行操作時(shí)的邏輯不同，如果為每個(gè)數(shù)據(jù)表的每個(gè)操作都單獨(dú)封裝個(gè)函數(shù)，光函數(shù)命名都夠我頭疼的了。那怎樣才能基于數(shù)據(jù)表、具有封裝性，又不用頭疼命名呢？可以說答案已經(jīng)呼之欲出了，當(dāng)然是使用 model，你可以為每個(gè)你經(jīng)常要操作的數(shù)據(jù)表單獨(dú)封裝一個(gè) model，需要時(shí)直接調(diào)用數(shù)據(jù)表所對應(yīng)的 model 的對應(yīng)操作即可，非常方便。

再說說我在前后端交互方面總結(jié)的經(jīng)驗(yàn)，前端給后端傳數(shù)據(jù)分為四種情況，如果數(shù)據(jù)量很小且不敏感，比如就一兩個(gè)字段，而且字段的值也很簡單，那就直接用 get 傳輸，如果字段比較多，數(shù)據(jù)量比較復(fù)雜或敏感，那就用 post 傳輸，如果需要在傳輸時(shí)維持?jǐn)?shù)據(jù)的結(jié)構(gòu)不變，比如你傳個(gè)對象或多維數(shù)組給后端，那就把數(shù)據(jù)轉(zhuǎn)換為 json 格式再傳輸，另外，如果需要通過 ajax 發(fā)送文件給后臺，就需要使用 FormData 對象。它的用法很簡單，直接將 form 節(jié)點(diǎn)傳遞給 FormData()，再用 xhr（我用 jq 封裝過的 ajax 會報(bào)錯(cuò)，所以只好換原生的 xhr 了） 的 send() 發(fā)送即可，如果還需要添加其它值，可以用 FormData.append() 為 formdata 對象添加 key/value。

最后，記幾個(gè)遇到的小坑：

1、form 內(nèi)的控件的 name 不能為 style，否則 form 本身的 style 屬性會被覆蓋，導(dǎo)致你無法通過 style 屬性更改 form 的標(biāo)簽內(nèi)嵌 css，進(jìn)而也會導(dǎo)致 jq 的 css() 方法失效。

2、mysql 建表時(shí)字段名不能為 key，否則會報(bào)語法錯(cuò)誤。

3、thinkphp 5.0 內(nèi)控制器的方法名不能為 result，否則會報(bào)錯(cuò)。

4、json 不支持關(guān)聯(lián)數(shù)組，json 只支持簡單值、對象、以數(shù)字為下標(biāo)的數(shù)組，所以 php 的關(guān)聯(lián)數(shù)組不能直接轉(zhuǎn)為 json 格式的字符串。

5、與路徑相關(guān)的東西千萬不要加中文字符，比如文件，這次我就遇到 php 的 move_uploaded_file() 不支持中文路徑。