Day 1: 1131228
一、目標:開發一個任務管理系統，並運用 MVC (model view controller)架構
二、預計使用工具:
(一)前端: JS的react - 對應 MVC 的 V 和 M
(二)後端: java spring boot- 對應 MVC 的 C 和 M

三、功能:
(一)使用者能夠登入
(二)輸入需求
輸入要防止sql injection和輸入錯誤提醒
(三)串接資料庫
資料庫設計(項目、內容、狀態變動)
(四)Dashboard進度條顯示

四、今日學習點:什麼是MVC?
(一)定義:
1.Model（模型）：應用程式的數據或狀態，負責處理業務邏輯。
2.View（視圖）：使用者界面，顯示數據和接受使用者互動。
3.Controller（控制器）：處理使用者請求和業務邏輯，並協調數據的流動。

(二)適用情境:
1.多層次功能的中大型應用
MVC的分層架構特別適合功能複雜、有多個模塊的應用，因為它將數據、業務邏輯與視圖分開管理。例如：
• 電子商務網站： 包含用戶管理、商品瀏覽、購物車、訂單管理等多模塊功能。
• 內容管理系統（CMS）： 例如WordPress或Drupal，允許用戶創建、編輯和管理內容。
• ERP系統： 涉及財務、供應鏈、客戶關係等模塊的企業管理系統。

2. 需要長期維護的項目
   • 特徵： 項目會隨時間增加新功能、進行調整或修復。
   • 原因： MVC架構的模塊化設計讓開發者可以輕鬆地維護和擴展功能，而不影響現有代碼。
   • 例子： 大型企業內部工具、社交媒體平台。

3. 團隊合作的項目
   • 特徵： 由多名開發者協作完成，開發分工明確。
   • 原因： MVC分離了數據處理、業務邏輯和UI，使前端和後端團隊可以獨立工作，減少衝突。
   • 例子： 像Uber、Airbnb這樣的應用程序，通常需要大規模協作來開發多個功能。

4. 需要多種視圖的應用
   • 特徵： 相同的業務邏輯需要在多種平台或設備上呈現（如Web、Mobile App、API）。
   • 原因： MVC架構將Model與View分離，業務邏輯可以重用，而僅需針對不同平台設計視圖。
   • 例子： 電子郵件系統（支持Web版和移動版）。

5. 數據密集型應用
   • 特徵： 須頻繁處理、查詢或更新數據，並根據數據生成視圖。
   • 原因： MVC的Model層專注於數據邏輯和處理，能有效管理複雜的數據結構和操作。
   • 例子： 大型數據儀表板、股票交易平台。

6. 動態且互動性高的應用
   • 特徵： 應用需要根據用戶輸入進行實時響應和數據更新。
   • 原因： Controller層負責管理用戶交互，Model層處理數據變更，View層則動態更新界面。
   • 例子：
   o 即時聊天應用
   o 任務管理工具（如Trello、Asana）

7. 高複雜度的Web應用
   • 特徵： 涉及用戶認證、角色管理、REST API集成等。
   • 原因： MVC可以很好地組織這些功能，避免邏輯混亂。
   • 例子：
   o 學習管理系統（LMS）
   o 在線預約系統（如醫療預約、餐廳訂位）

(三)優點:

1. 清晰的分層結構
   • 分離關注點：將業務邏輯（Model）、用戶界面（View）和交互控制（Controller）分開，使得每一層的職責更加清晰。
   • 易於維護：修改某一層的邏輯時，不會影響到其他層，減少代碼耦合。
2. 便於測試
   • 獨立測試：每一部分都可以單獨測試，例如業務邏輯測試 Model，界面測試 View。
   • 單元測試：因為業務邏輯和界面分離，可以更專注於測試核心功能。
3. 可重用性高
   • Model 可重用：可以在不同的應用中重用相同的數據和業務邏輯。
   • View 可替換：例如，當需要更改界面設計時，只需修改 View 層，Model 和 Controller 可以保持不變。
4. 便於協作開發
   • 分工明確：前端工程師可以專注於 View，後端工程師專注於 Model 和 Controller。
   • 同時開發：多個開發人員可以並行工作，提高開發效率。
5. 可擴展性強
   • 支持增量開發：可以在現有結構上添加新功能，而不需要大幅修改現有代碼。
   • 應用場景廣泛：適用於大多數複雜的應用程序，尤其是那些需要頻繁更新的項目。

(四)劣勢:

1. 增加了初期的複雜性
   • 結構較重：需要設計和實現三個部分（Model、View、Controller），對於小型項目來說，可能顯得過於繁瑣。
   • 學習曲線：初學者需要理解每個部分的職責，以及它們之間的交互方式。
2. 需要更多的代碼
   • 冗長的代碼：將邏輯分開可能需要撰寫更多的樣板代碼（boilerplate），尤其是在處理簡單功能時。
   • 文件分散：應用可能包含大量的文件和類，管理起來可能會變得複雜。
3. 高耦合的 Controller 和 View
   • Controller 的負擔：Controller 需要處理用戶請求，與 View 進行交互，可能會導致 Controller 成為項目的瓶頸。
   • View 依賴 Controller：某些情況下，View 和 Controller 的交互可能過於緊密，增加了耦合。
4. 不適用於小型項目
   • 過度設計：對於簡單應用，MVC 可能帶來不必要的複雜性，導致開發效率降低。
   • 不必要的分層：小型應用通常可以直接將邏輯和界面(像是html裡面的script)集成在一起，MVC 的分層反而成為一種負擔。
5. 隱藏的性能問題
   • 頻繁的數據更新：當 Model 發生變化時，必須通知 View，這可能導致性能瓶頸，尤其是數據量大時。
   • 同步挑戰：確保 Model 和 View 的狀態一致性需要額外的代碼和邏輯。