傳統面向過程採 Input-Processing-Output 模式，受限於 DOS 單任務。Windows 圖形介面下，MVC (Model-View-Con

建議先至官網下載最新版安裝體驗，文檔極完善（含代碼級差異對照）。 發展脈絡 ASP.NET Starter Kits - ASP.NET Portal：

DNN 框架可從目錄結構與核心功能兩維度劃分： 一、目錄結構 Admin（管理）： Container、File、ModuleDefinitions、P

近兩個月以 DNN 為原型研發系統，總結出 DNN 核心硬傷：過度鬆散。非指模組佈局彈性，而是內容管理缺乏集中性。 痛點實例：公告與文章管理 發公告：只

我偏好高自由度、列表導向的模組，而非單純編輯器。Text/HTML 模組無歷史痕跡，修改即覆蓋，不利內容追溯。Forum 模組 CSS 強綁定、視覺風格難整合。

Reports 模組極簡單強大：用 SELECT 將既有資料重組為新模組。新版支援 Visualizer（視覺化器），列表呈現方式開放（Grid/HTML/XS

本篇回應讀者留言，補充 Reports 模組實用細節。 分頁功能早已內建 新版 Reports 設定介面直接支援分頁，極簡單。詢問此問題者顯未實際使用。 樣

UDT 以三張表支撐無限欄位動態表單，結構極度精簡：UserDefinedFields（結構定義）、UserDefinedRows（主鍵）、UserDefine

2006 年底曾與 UDT 作者 Sebastian Leupold 郵件討論資料結構，覺得原設計難懂，建議優化未果，決定自行重構。以下分析 UDT 原結構與優

早期我極少撰寫預存程序，覺得修改資料結構（加欄位、改型別）需同步改動資料表、SP、呼叫端，極繁瑣。但習慣後發現 SP 確有優勢，被迫養成嚴謹設計習慣。DNN 安

目標：讓 DotNetNuke 不僅支援 Internet 門戶，亦能承載 Intranet 內部業務系統。Intranet 業務邏輯往往更複雜，需引入組織架構

組織架構本質為樹狀結構，這是拋棄 DNN 原生「安全角色」（扁平化）另建架構的主因。兩者定位不同：安全角色管控系統權限（頁面/模組存取），組織架構管控業務數據權

組織架構開發完成後，可在系統中新增部門與人員。但 DNN 在「管理模組」整合上存在短板：Joomla/Drupal 可輕易擴充後台管理選單，DNN 僅能透過 I

背景： 早期整理於 Google Docs 的思考筆記，為完整呈現解決歷程，分三篇發表。 核心痛點：單一 Default.aspx 的限制 運行中的 DotN

為實現新視窗編輯/檢視內容，需自建 Edit.aspx。但這不會破壞 DNN 架構，只要遵守四大原則：不影響開發結構、不任意增刪現有結構、確保無新頁面時 DNN

前文已介紹透過「擦邊球」手法讓 DotNetNuke 符合國人瀏覽習慣（新視窗開啟內容），核心修改如下： 網站根目錄新增 Edit.aspx，並修改其載入

在使用 DotNetNuke 過程中，我對其 UserDefinedTable (UDT) 模組深感興趣，並深入研究其資料結構與程式碼。UDT 的開發模式極具參

承接上篇，我們探討如何讓使用者擁有最大彈性自訂表單外觀。最終的表單樣板檔案（.ascx 或 .html）結構如下，採用純 HTML + CSS 設計，並預留 &

在 DotNetNuke 開發自訂模組時，對私有組件進行除錯是必要技能。以下是完整的操作步驟，助你快速建立除錯環境。 除錯前置準備 以瀏覽器開啟 Dot

在 DotNetNuke 3.0 版本中，若使用英文版安裝，資料庫中的大多數資料表名稱都會帶有「_DNN」前綴。這個前綴並非隨意加入，而是透過 objectQu