在電商系統中，商品模型至關重要，是整個電商的核心，下面通過乙個簡單的分析，設計乙個基礎的商品模型。
商品模型的演化
在以前，那時cms很流行，最常見的模型是欄目-文章模型。於是做電商的時候，自然就繼承了這種一對多的關係。只是欄目變成了分類，文章變成了商品。商品也具備了獨特的業務屬性。現在很多電商**上左側的選單，也就是這個分類。
後來我們慢慢發現乙個問題，只有分類並不能適應所有的需求，比如nike鞋和niket恤，使用者可能希望先看nike的所有商品，這個模型就不能滿足。我們想在這個關係中，加入「品牌」概念。於是：
這樣基本使用者可以在首頁上通過分類或者品牌找到自己想要的商品，也可以直接檢視熱門的商品和新上架的商品。但是問題也來了，使用者在進入分類後，展示在使用者面前的是很多很多商品，使用者希望再通過篩選查詢出更接近他目標的商品。於是優秀的產品設計師，設計出了類似這樣的ui：
使用者可以通過這些篩選條件進一步縮小自己的目標範圍，那麼問題又來了，這樣的產品需求排在程式設計師面前，怎麼去實現它？經過分析，我們找出了乙個方法，我們知道商品之間的屬性可能存在著較大的差別，比如牛仔褲它有版型、腰型、褲長等屬性；而電腦它有cpu、顯示卡等屬性，各類商品的屬性是不同的。再進一步想，休閒褲也版型、腰型、褲長等屬性；台式電腦或者膝上型電腦都有cpu、顯示卡等屬性。所以我們得出：乙個分類對應若干屬性，而乙個屬性，對應若干屬性選項，而乙個具體商品又對應若干屬性選項（例如具體一條牛仔褲，他的褲長：7分，褲型：直筒）。有點繞，仔細品味一下。
從圖上可以看出，分類和屬性的關係（例如：「牛仔褲」分類下有褲型、褲長、版型等屬性）、屬性和屬性選項的關係（例如：褲長屬性有長款、九分褲、七分褲的選項）、商品和屬性選項的關係（例如某條牛仔褲的褲長是7分褲）。至此，我們知道乙個商品的分類、品牌以及它有什麼屬性和對應的屬性值。那麼通過篩選條件，自然就可以查詢出指定的商品。這裡特別說一句，**也是屬性，不要設想用商品表中的**欄位去做計算。這不利於查詢也增加了複雜度，讓商家編輯人員用屬性來設定並保證他的正確性。
這個頁面展示商品的所有資訊，按照之前的設計好像都可以滿足。但是我們似乎感覺錯過了什麼，在圖上右邊我們發現該商品當前的顏色和尺寸，並且允許使用者可以選擇其他的顏色和尺寸。這給我們帶來了疑惑，這裡的「顏色」和「尺寸」是什麼，一件商品的不同顏色不同尺寸是算乙個商品還是多個商品。經過思考後，我們發現我們混淆了兩個概念——「商品」和「貨品」。不同規格的貨品作為獨立的商品。比如一條褲子的有l尺寸、m尺寸、乙個u盤有16g還是32g的，都是同樣的貨品，不同規格的商品。可以認為貨品和商品是一對多的關係。弄清了這個概念，處理這個需求就容易多了，這裡的「顏色」、「尺寸」我們就作為「規格」來處理，而紅色、黑色；l號、m號我們視為規格的選項或者說規格值。一件貨品對應若干規格，而具有某一規格值的貨品就是商品。
好了，現在好像差不多了。基於這個模型可以滿足基本的商品搜尋、展示的需求。搜尋引擎也可以根據這個模型資料生成對應的商品索引，達到準確搜尋的目的。商品模組還會和其他模組一起協作，比如使用者系統、訂單系統、支付系統等。一般情況下我們會把商品業務獨立出來做成「商品中心」的服務，集中處理商品查詢、更新、發布等業務，支撐其他業務。
建立實體類
下面直奔今天的主題 建立實體類 一點小插曲 接觸abp框架之前，一直都是使用的ef的dbfirst,在那種模式下，我們只要設計好資料庫，然後直接通過模板就生成了實體層，甚至都沒怎麼留意實體層的 是什麼樣子。現在要使用codefirst，就要反過來，先要寫 了，真有點不適應。好吧，為了學好abp，也要...
業務邏輯層實體類Model分析
業務邏輯層實體類 model分析 1 業務邏輯層 1 業務專案實體分析 model 分析 petshop 中的九大業務資訊 1 訂單資訊 orderinfo 2 單個寵物資訊 iteminfo 3 寵物類別資訊 categoryinfo 4 寵物目錄資訊 productinfo 5 購物車 意向清單...
字典實體類 DictionaryEntry類
dictionaryentry類是乙個字典集合，主要包含的內容是鍵 值對。這種組合方式可以方便地定位資料，其中的 鍵 具備唯一性，類似於資料庫中的 id 乙個id對應一天記錄，而乙個鍵只對應乙個值。使用dictionaryenry類可以方便地設定和檢索資料。雖然被稱為字典集合，但dictionary...