思考：

　　項目定位清晰，每日的數據量大小，最高並發預測

　　項目方向確定，電商？信息系統？采集系統？

　　項目是否會進行多次升級（二次需求）？

　　項目是否會持續維護？

　　項目是否會面臨數據庫的遷移？

　　項目數據的重要性程度？

根據文件大小及量，項目方向確定你的基礎框架是否需要做圖片或文件服務器，並發瓶頸是否需要做數據庫的橫向擴展或是數據庫集群，項目的分布式或反向代理，項目的自動化保證維護的簡易性，面臨瓶頸時數據分類新增其它類型數據庫，海量（非重要數據）的定時清除特麽對於遊戲

搭建：

　　（1）領域層級（實體類，倉儲服務接口（邏輯單元具體實現））

　　（2）數據庫Entity（搭建一套可用易擴展維護的Entity()實體對象CRUD的倉儲）

　　（3）應用層Application（接口+實現+Dto 邏輯單元組合）

　　（4）Web層級（表現層或者對外接口）

　　（5）Utility 一些支持類（數據類型轉化，導出，圖文件讀寫，算法支持，網絡訪問，類型擴展，代碼生成...）

　　（6）EntityFrameWork 核心實現（基於DBContect的倉儲基類的實現，各個對象倉儲的實現）

（1）基礎權限

（2）登錄.........

基礎框架的搭建分層