觀察 MVC 的設計思維，可以得知：畫面的設計並不是軟體設計的重心首在，畫面是手段，僅是為了表達展示給操作使用者來觀看的，若有更好的畫面呈現方式，系統可以整個抽離掉畫面而不致影響核心，就好比樹葉會代謝再長出新葉也是為了讓整棵樹能呈現更茂盛的一面。
同樣地，資料庫也是手段，是資料儲存的倉庫。若因為分散及負荷的因素，則需考慮配置多個資料庫，甚至，有效能更好、更便宜的資料庫，則隨時可更換之。
畫面(View)與資料庫都是手段，目的即是為了要能維護軟體的主幹–來自專業領域(Problem Domain)上的概念(Domain Concepts)，概念往往成為軟體設計內的企業元件(Business Component)。
為了要能維護企業元件不因外在環境的變動而牽動，進而提升系統的彈性度及增進再利用的價值，軟體開發人員，要能考慮：
- 變與不變的相對性。
- 虛與實的相依性。
同時，又要能兼顧系統的效率與問題與使用者的便利性，也要能瞭解：
- Stateless 與 Stateful 物件相互的配合。
★變與不變
“變” 與 “不變” 是一種相對性的關係，不是絕對的“變”或絕對的“不變”。觀察：
- Presentation -> 易變 ; Database -> 變動幅度較小 ; Middleware -> 較穩定
- 子系統(SubSystem) or 模組(Module)元件 -> 善變 ; 本質性(Entity)元件(Component) -> 穩定。
- 企業流程 -> 善變 ; Domain Concept -> 穩定。
- View -> 易變 ; Control -> 變動幅度較小 ; Model -> 最具穩定性。
- Boundary -> 易變 ; Control -> 變動幅度較小 ; Entity -> 最具穩定性。
- 屬性(Attributes) -> 善變 ; 物件(Object) -> 穩定
- 介面(Interface) -> 穩定 ; “Realize” 該介面的物件 -> 易變
★虛與實
容易變動的部分，宜採用 “虛” 的設計，也就是說，不直接落實企業邏輯的責任於易變的部分。觀察：
- 畫面與資料庫是易變動的部分，所以不負責處理企業邏輯 ; 可以這麼說，為了要能履行畫面上所呈現的功能(Function)，該功能的落實，不會寫在畫面或資料庫上。
- 子系統是善變的，所以，子系統與子系統間所溝通的介面是不穩定，要以“虛”的設計來承擔其變動，也就是說，該介面僅是訊息溝通的管道(Request、Response)，而由穩定的元件來落實。
- 由上點推論，擔任子系統溝通的介面的 Web Service 物件，就不宜以“實”的方式來設計。
- 控制物件接收至 View 所傳送過來的需求，它是屬於流程物件(Process Object)或功能物件(Function Object)並將該需求協調及轉派給適當的企業物件(Business Object)來處理，所以，它也是“虛”的物件。
- 由使用者的需求所構成的“流程”，宜由最具穩定來自於領域概念上的企業物件來落實，才能快速的“組裝”動態多變的流程。所以，企業物件或稱之為企業元件(Business Component)，來擔任“實”的設計。
★Stateless 與 Stateful
從 State + “less” or “ful” 的字義來看，顯然的，主要是以 “狀態(state)” 來作區分。不保存狀態，就為 “stateless” ; 而可以保存 Client 與 Server 之間的狀態，就稱為 “stateful”。
會因狀態的保留與否而區分為 Stateless 或 Stateful 物件，最主要就是考量到 Server 可利用的資源(Resource)有限。
傳統的OO物件大多著重於stateful物件，像UML也不著重stateless物件的探討與表達。然而，在今天的middleware（如EJB或COM+/MTS）裡stateless 物件卻大放異采，甚至掩蓋過傳統OO所青睞的stateful物件呢！
尤其，在EJB架構裡，有非常重要的用途。如R. Monson-Haefel [Mon99, p.175]所說：
“Stateless session beans require few server resources because they are neither persistent nor dedicateed to one client. Because they aren‘t not dedicated to one client, many EJB objects can use just a few instances of a stateless bean.”
(stateless 的session元件不須要長存其狀態值，也不專屬於特定的client，所以其佔用server的資源較少。也由於不隸屬於特定的client，所以許多EJB物件可共用少數的stateless 元件 。)
Stateless物件就像計程車，並不是專為某位顧客服務，只要少數的計程車就可為極多數的客人服務。 至於stateful元件則像自用轎車，每部只服務特定的顧客，常需要較多的停車場（即佔用server資源較多）。
當您呼叫計程車時，並不會指明要上次所搭那一輛計程車。同理，client使用stateless物件時，心裡必須明白stateless物件與stateful物件的不同假設，就如R. Monson-Haefel [Mon99, p.176]所說：
“A client can‘t assume that the same bean instance will service it every time.”
(client物件不能認為每次叫用時，都是由同一個物件個體來為其服務。)
因之，stateless物件的特性為：就client而言，在意的是server物件的外在行為，而行為又跟物件的狀態無關，所以client物件不必在意物件狀態的變化，而不是此種物件真的沒有狀態。就如R. Monson-Haefel [Mon99, p.175]所說：
“These restrictions don‘t mean that a stateless session bean can’t have instance variables and therefore some kind of internal state. …. However, it‘s important to remember that this state can never be visible to a client.”
(這些限制並不意謂著stateless 的session bean 不能有屬性變數，因此意謂著可以有其內部狀態。然而重要的是，client不會看到這些內部狀態。）
然而，像前面已經談過，stateless物件像計程車，stateful物件像自用轎車。stateless物件馬不停蹄地轉檯，為不同的client服務，所以stateless的再用性(reusability)非常高，而stateful物件專屬於特定顧客，常出現「佔在毛坑不拉屎」的情形，因為再用率低而造成資源的浪費。所以R. Monson-Haefel [Mon99, p.175]說：
“A stateless session bean is relatively easy to develop, and also very efficient. Stateless session beans require few server resources …. In short, they are lightweight and fast!”
(無狀態的session bean比較容易開發，也比較有效率。無狀態的session bean需節省server的資源 …. 簡而言之，它們輕盈而快速。）
在Internet時代裡，資訊系統的延展性(scalability)卻是重要無比，而高度延展性的前提必須有效運用server的資源，使得stateless物件的輕盈快速，成為極為亮麗而有價值的特性。在開發N-tier系統時，活用stateless物件成為系統設計師的必備技能。