@Jack.Wang
你誤導(dǎo)了太多的人。。
。。。。。
現(xiàn)在對(duì)于常量池的解釋一片混亂。
說(shuō) 在堆區(qū) 在棧區(qū) 在靜態(tài)區(qū) 在數(shù)據(jù)區(qū) 的都有。。
媽的。。。

不錯(cuò)。。。還有研究 dump文件的阿 不錯(cuò)不錯(cuò)呵呵

朋友是bea的？ 。。。 我們公司用了spring作了框架 然后再weblogic中 redeploy的話似乎spring的context沒(méi)有被銷(xiāo)毀。 我們已經(jīng)在listener中調(diào)用了context的關(guān)閉銷(xiāo)毀方法但是似乎沒(méi)啥效果。。。 redeploy多次后java heap就不行了。。。 不知道其他地方有沒(méi)有這種情況？？？？？

@arlen
以前我的想法與你一樣。我在我們公司的一體化項(xiàng)目中極力推薦其他架構(gòu)。但是由于各種原因最后還是用了這種table module架構(gòu)。

結(jié)果發(fā)現(xiàn)，使用這種應(yīng)用架構(gòu)在強(qiáng)依賴(lài)于關(guān)系數(shù)據(jù)的應(yīng)用中卻是有效。

之前在看PoEAA中提到，能夠與“TABLE”交互的接口越多這種模式約有效。
在實(shí)踐過(guò)程中發(fā)現(xiàn)，其實(shí)只要提供一種通用的簡(jiǎn)潔的序列化方式既可。比如，在于界面交互式（尤其是HTTP的web方式）可以用JSON來(lái)實(shí)現(xiàn)序列化過(guò)程。對(duì)于數(shù)據(jù)庫(kù)接口的交互其實(shí)就是一個(gè)加了循環(huán)的Record處理。

關(guān)于你提到的TABLE存儲(chǔ)在那里？ 其實(shí)這個(gè)問(wèn)題很簡(jiǎn)單，因?yàn)榇蟛糠制髽I(yè)應(yīng)用都是“事務(wù)”應(yīng)用所以，在一個(gè)Tx中提交這些數(shù)據(jù)到數(shù)據(jù)庫(kù)就結(jié)束了。

很久沒(méi)有上來(lái)了，那個(gè)一體化項(xiàng)目作了1年多了。呵呵。要好好總結(jié)一下。

4.1是周六。。。 還上班。。。 上班還出事故。。 真背啊。。。

我們公司有個(gè)部門(mén) 就使用這個(gè)作為界面基礎(chǔ)的。。。。不過(guò)。。。性能好像有點(diǎn)問(wèn)題。。。

事實(shí)上 即便自己覺(jué)得理解了 還是會(huì)跟你所講的原意有所出入。。。 。。。 hoho

為啥要用 斜體字。。。 看起來(lái)實(shí)在難受啊。。。。。。。。。。。。。。。。

只談結(jié)構(gòu)是否缺少行為表述呢？？還是認(rèn)為結(jié)構(gòu)描述先天由于行為描述？？


“.....著它們處于復(fù)雜性的不同級(jí)列（可以實(shí)現(xiàn)平滑的過(guò)渡）...”
又看到這個(gè)詞了 -_-b

樓主的注釋寫(xiě)錯(cuò)了。。。 被注冊(cè)到shutdownhook上的是TestShutdownHook的實(shí)例作清理工作的也是TestShutdownHook的run() 他將無(wú)限循環(huán)的TestThread.run()中止了。

恩。。。 是的，許多事務(wù)組件其實(shí)已經(jīng)實(shí)現(xiàn)了提到的所模式。我這里只是說(shuō)明一下，原理而已。嘿嘿。。。

。。。jdon 還是有些份量的。。。 和javaeye 一樣 都是有年頭的。。。

還有 抽象 本身不只是軟件工程的東西，而是哲學(xué)的東西，軟件工程只是借用。

比較期待 你的來(lái)自自然科學(xué) 級(jí)列論

不要用某些人啦。。。 那個(gè)只是我個(gè)人觀點(diǎn)啦。。。。

......對(duì)于你的一般性 基本知道是根抽象性有區(qū)別了 。。。。。。不過(guò)說(shuō)老實(shí)話 相對(duì)論沒(méi)zm學(xué) 所以還是不太理解你舉的例子 能不能舉個(gè) 通俗點(diǎn)的例子。。。

關(guān)于

service層, data object層, dao層
其實(shí) 只是分析到某個(gè)抽象層次。。。職責(zé) 分類(lèi)。。。而且有個(gè)問(wèn)題環(huán)境 就是“ 交互型應(yīng)用來(lái)說(shuō)的”

你說(shuō)：“. 但實(shí)際上, 我們肯定可以想見(jiàn)更加復(fù)雜的情形, 僅僅三層并不足以充分表達(dá)程序的結(jié)構(gòu)”
確實(shí)是這樣，然而問(wèn)題是就像你批評(píng)說(shuō)的“有哪么復(fù)雜么”。既然，大家都知道，過(guò)于復(fù)雜就無(wú)用的。哪只分析到一個(gè)一般人能夠接受的復(fù)雜程度就停止。難道有錯(cuò)？
其實(shí)我只是想說(shuō)明 問(wèn)題出在人們?cè)趯?shí)現(xiàn)中濫用這些東西 。分析出這些東西的本身無(wú)可厚非。

還有：關(guān)于你舉的例子 你說(shuō)的只有 crud。。。 這里假設(shè)你所指crud是 這些方法或函數(shù)以及參數(shù)就是 服務(wù)接口的職責(zé) 其實(shí)更service 處于同一職責(zé)。。。 crud內(nèi)部比然有對(duì)狀態(tài)的處理以保證這些crud的功能就是預(yù)想的那樣。。。 其實(shí)些東西的更 domain object 層次職責(zé)一樣。 （說(shuō)老實(shí)話 data object我沒(méi)有看到過(guò)）
dao層 與 crud 中直接跟你的“數(shù)據(jù)庫(kù)” 交互的部分 其職責(zé)也使相近的。

如果要按照你的級(jí)列理論來(lái)說(shuō)： 這里的職責(zé)也更你舉的例子是不同緯度的級(jí)列層次。

怎么不發(fā)到 架構(gòu)師之家來(lái)呢？

我也寒一下。。。。。。。。。。。。。。。看來(lái)你學(xué)到了模式的精髓了。。。。。

不知道可不可以這樣理解。
你所指的“一般”與“特殊”就是： “相對(duì)抽象” 以及 “相對(duì)具體”。
你所指的“一般”到“特殊”，“特殊”到“一般”連個(gè)方向就是指：具化過(guò)程，抽象泛化過(guò)程，這兩個(gè)過(guò)程。

而級(jí)列就是指“相對(duì)抽象” 與“相對(duì)具體”存在著不同抽象層次。而且這寫(xiě)層次客觀存在并且連續(xù)。

關(guān)于 你所說(shuō)的“偏偏要在service層, data object層, dao層”部分可能你沒(méi)有理解定義這些層次的原始意義。 這些東西只是對(duì)“職責(zé)”的描述并不是實(shí)現(xiàn)，在實(shí)現(xiàn)中應(yīng)該根據(jù)實(shí)際情況進(jìn)行合并與取舍。而且這些“職責(zé)”也是由“事務(wù)”(這里并不是指原子操作的概念)這個(gè)職責(zé)具化而來(lái)。 我想你也應(yīng)該知道一旦具化（特殊化），適用范圍就變小了。

不錯(cuò)啊。。。 以前還沒(méi)用過(guò)這個(gè)。。。 先收了

haha... OO 被你們討論成這樣 我也夠佩服的。。。

我覺(jué)得你們?nèi)プC明或取否定基礎(chǔ)都沒(méi)有意義。。。
因?yàn)椋?
1。OO本來(lái)是哲學(xué)概念。
2。OO是用來(lái)描述的，不是用來(lái)計(jì)算和證明的。
3。任何體系都沒(méi)有辦法證明自己的正確性，而只是基于一些公理存在，而這些公理指在于信與不信。


不過(guò)我覺(jué)得還是很有分量的。。。 先收了。。。。

對(duì)于“可退化性“ 不太了解
請(qǐng)問(wèn) 根據(jù)你的定義
“架構(gòu)的可退化性(degragation)指的是架構(gòu)的結(jié)構(gòu)可以從元素比較豐富,層次比較多,比較復(fù)雜的情況退化到比較簡(jiǎn)單的情況“

是不是 退化就是指 不同職責(zé)部分 的合并但是這些職責(zé)依然存在？

我想 對(duì)于這樣非常理論化的歸納 估計(jì)很多人都不愿意看。 不過(guò)作為以后杜撰文章的，可復(fù)用模塊是不錯(cuò)的材料。。。。呵呵

我個(gè)人感覺(jué)還是，比較接近的。
之所以現(xiàn)今的軟件架構(gòu)與建筑架構(gòu)有較大差異，主要是因?yàn)檐浖I(lǐng)域和建筑領(lǐng)域的發(fā)展階段不同。一個(gè)幾十年，一個(gè)上千年了。成熟度不一樣。如果類(lèi)比現(xiàn)今的軟件領(lǐng)域和早期的建筑領(lǐng)域會(huì)發(fā)現(xiàn)很多共同點(diǎn)的。

不錯(cuò)不錯(cuò)。

軟件架構(gòu)師注重整體把握，高級(jí)程序員負(fù)責(zé)細(xì)節(jié)精華。者這個(gè)觀點(diǎn)來(lái)說(shuō)，兩者級(jí)別是一樣的，只是關(guān)注點(diǎn)不同。

“另外作為架構(gòu)師還要考慮的問(wèn)題很多，甚至比技術(shù)架構(gòu)更重要如授權(quán)模式、部署模式及成本、維護(hù)方案、安裝及升級(jí)方案、商標(biāo)及商標(biāo)的相關(guān)元素、發(fā)布及發(fā)布管理、安全因素、市場(chǎng)因素及技術(shù)市場(chǎng)架構(gòu)（個(gè)人認(rèn)為這個(gè)因素最難也最重要）“
。。。。。。。。。這個(gè)好像已經(jīng)上升到系統(tǒng)分析級(jí)別了。。。該角色關(guān)注范圍比構(gòu)架師跟廣。

你好，算我一個(gè)把。軟件構(gòu)架師我是我職業(yè)生涯的的一個(gè)中期目標(biāo)。現(xiàn)在雖然經(jīng)驗(yàn)項(xiàng)目經(jīng)驗(yàn)不多，不過(guò)我自以為對(duì)事務(wù)系統(tǒng)的整體多少有點(diǎn)把握。現(xiàn)在，正準(zhǔn)備總結(jié)一下自己在這方面的一些觀點(diǎn)，并準(zhǔn)備花較常時(shí)間學(xué)習(xí)研究一下軟件集成的設(shè)計(jì)與構(gòu)架。剛申請(qǐng)blog 現(xiàn)在上還沒(méi)有啥東西。。。http://m.tkk7.com/wfeng007