果然被淘汰了，和我想的差不多，原因是我覺得它太復雜了，我喜歡那種一看上去就清晰簡單的東西，而且要容易理解。一個好的架構應該可以抽象成現實生活中有的“東西”，這樣理解起來就容易多了。
我學“面向對象設計”的時候，發現一個問題，那就是對象的“方法”問題，比如對象要是人的話，他有一個“提交”，或者是“檢查”的方法，那是很容易理解的。但是比如有個“表單類”，其中他的方法“添加”。我覺得它這個方法是“被動”的，因為表單自己并不會“添加”，施加給它這個“動作”，或者是“方法”的，應該是個人。所以我認為，我們建模的時候為什么不把一個過程抽象為現實生活中的過程呢，也許它的性能會低一些。雖然我還沒有具體去實踐，也還沒有學過什么J2EE，但是我把我的想法說說：
比如架構一個系統，要涉及到權限，要涉及到功能的“開”，“關”，最基本的做法，我們做每一個操作之前，總是要查詢“這個功能被系統打開了或者是關閉了沒”，“我們是不是有這個權限”，很自然的，比如是個注冊系統，我們在執行“添加”這個動作之前，都必須用到兩個方法，第一個檢查這個“注冊”功能是不是正被開放使用，第二個，我們是不是有這個“權限”進行“添加”操作？那這兩個類，我們應該放在哪個類里面去呢，也許我們可以把他分成兩個類（權限類，功能類），然后在“注冊類”里面加上這兩個方法，在執行“添加”之前操作他們。我覺得這樣增加了他們之間的“耦合”，也顯得很混亂，在一個類里面執行這些操作，是不是把“注冊類”這個靜的東西動態了？執行這些操作的應該是個人才對?。烤拖笤诂F實世界中，我們填寫完一張注冊表之后，我們并不會直接去“檢查”，“添加”他，我們會把他交個一個這方面的人，然后這個人會檢查，我是不是有這個權限？我填寫的完整沒有？然后他跟“注冊類”打交道。也就是,用戶――>“負責注冊模塊的人”――>注冊類。這樣打交道。
權限和功能問題：我們要進行操作時，先找個負責這個操作的人，然后他告訴我，比如，“這個功能被關閉了”，“你的操作已經成功了”，之類，我們不直接跟類打交道，因為我們不能充當每方面的“專家”
這樣做的好處，松耦合，也省的每次執行操作之前都要在方法里面嵌套方法，我們可以等用戶登陸的時候，就找到那個相關的人，把系統的功能開放了哪些和這個人可以進行的操作記錄在表里，進行操作的時候就不必再查數據庫了，應該更快些？然后用戶退出的時候，就刪除相關的記錄？
我覺得MVC模式里面的C，有時候他就充當了“這個人”的角色，但其實這個人可以分的更細些。
這些問題我也是剛想的，你們的想法是？或者，說說這樣做的缺陷
|
|