現在專案中使用的架構大概如下圖，乙個典型的分層架構，從petshop學習得來，當時認為業務邏輯是不可能更換的，所以便去掉了ibll層，但是現在看來這一層還是很有必要的，不同的時候看同一件事就會有不同的看法。
ui層主要是收集資料和顯示資料。
model層主要是一些貧血的實體類。
bll層主要負責業務邏輯的處理。
idal是資料訪問介面層。
dalfactory主要負責資料訪問物件的構造，這裡主要是用到了反射來建立物件。
dal層實現資料訪問介面。
這個分層架構的好處是各個層的職責更加明確，同時由於通過介面來處理資料儲存，所以理論上可以實現多資料庫支援。
對於一般的專案，這個架構也算是足夠了。
但是仔細分析會發現有很多問題：
各層之間的相互依賴太多。model層幾乎被所有的層引用，除了dalfactory
雖然架構上可以支援多資料庫， 但是如果真的通過新建專案的方式來支援多資料庫的話，則工作量太大。
一般專案都會包含多個模組， 這樣各個模組的**都會混在一起，等到要拆分或者移植到其它系統的時候會發覺各個模組的**耦合在了一起，不好分離。
如果現在讓我重新來設計的話，我會採用下面的架構：
將model層， idal資料訪問介面層和ibll介面層的**放到乙個專案中， 暫時稱為模組核心層，即core層。
有乙個獨立的核心元件， 包括建立物件的工廠，持久層框架，日誌，快取和工具類等。
各個模組之間的依賴通過介面來解決。
這樣，各個模組的可移植性就增強了。
最好還有這樣乙個功能，像csla中的一樣，比如建立了乙個windows客戶端， 可以直接連線資料庫進行操作， 也可以從連線web service時行操作，還可以連線remoting進行操作， 在這之間的切換只需要修改一下配置就可以了，但只需要寫乙個業務邏輯，不用在專案中強制引用web service，這樣就更完美了。
大家有什麼看法？
關於實時架構的一點想法
近來做了乙個大屏的大專案 效果類似於下圖的那種 說是要做到資料實時，甚至把物聯網的那一套東西都接進來實時監控！大屏指揮中心效果圖，來自dreamstime.com 最後在徵求多方專家的建議，綜合評估各大方面的情況後後得出一方案是 其實，這樣從資料產生，直到前端顯示，差了好幾分鐘。資料 資料 可以很多...
關於專案對於Mode層分層的一點總結
專案最開始，只是運用了簡單的mvc架構，對於m層，沒有更好的區分。並且對於資料庫操作，業務物件，業務邏輯混為一體，對於後期很難維護。後專案進行了分層，對於m層進行了分層設計，大致分為三層 service，bo，dao。service 處理業務的 放在這裡。bo 建立業務物件。方便各個模組進行呼叫，方...
關於Linux STL使用的一點總結
前兩天發現linux使用stl的程式記憶體占用比較大，通過valgrind檢查沒有發現記憶體洩露，分析可能與stl有關，所以單獨對stl進行測試 程式新建10個執行緒，採用分離方式，每隔2秒建立乙個執行緒。1.對new 與 delete的測試 在每個執行緒中new 很大一塊記憶體，然後間隔20s後d...