實戰分層架構（四）：實體類別設計與實作——貧血模型在層間傳遞的純粹踐行

實體類別的角色定位

實體類別是領域概念在程式碼中的映射，**貫穿全架構**，承擔層間資料傳遞職責。本專案採用 **貧血模型**：僅包含屬性（資料），不包含業務邏輯與關係行為。對應資料庫實體表一一映射，屬性對應欄位。

專案結構與 Entity 專案位置

• Web：表示層
• Entity：實體類別（獨立專案，被所有層參考）
• Factory：DI/IoC 相關
• IBLL：業務邏輯介面
• IDAL：資料存取介面
• Utility：工具/輔助類

三大核心實體類別完整程式碼

AdminInfo：管理員實體

[Serializable]
public class AdminInfo
{
    private int id;
    private string name;
    private string password;

    public int ID { get => id; set => id = value; }
    public string Name { get => name; set => name = value; }
    public string Password { get => password; set => password = value; }
}

MessageInfo：留言實體

[Serializable]
public class MessageInfo
{
    private int id;
    private string guestName;
    private string guestEmail;
    private string content;
    private DateTime time;
    private string reply;
    private string isPass;

    public int ID { get => id; set => id = value; }
    public string GuestName { get => guestName; set => guestName = value; }
    public string GuestEmail { get => guestEmail; set => guestEmail = value; }
    public string Content { get => content; set => content = value; }
    public DateTime Time { get => time; set => time = value; }
    public string Reply { get => reply; set => reply = value; }
    public string IsPass { get => isPass; set => isPass = value; }
}

CommentInfo：評論實體

[Serializable]
public class CommentInfo
{
    private int id;
    private string content;
    private DateTime time;
    private int message; // 對應 MessageID 外鍵

    public int ID { get => id; set => id = value; }
    public string Content { get => content; set => content = value; }
    public DateTime Time { get => time; set => time = value; }
    public int Message { get => message; set => message = value; }
}

設計細節說明

• [Serializable]：支援跨應用程式域傳遞、Session 狀態儲存、遠端呼叫序列化。
• 私有欄位 + 公有屬性：封裝資料，未來可在 setter 加入驗證邏輯而不影響呼叫端。
• 無邏輯、無行為：純資料容器，符合貧血模型定義。業務規則置於 BLL，資料存取置於 DAL。
• 命名對應：屬性名稱與資料庫欄位名稱一致（如 ID、GuestName），降低映射認知負擔。
• 型別選擇：IsPass 用 string 而非 bool，因 Access 欄位為 varchar(10) 存「Y/N」；Message 為 int 對應外鍵。

為何不使用充血模型？

在三層架構中，充血模型易導致「領域邏輯外洩至表示層」或「資料存取邏輯混入實體」，模糊層次職責。貧血模型配合 Service Layer（BLL）明確分離關注點，更適合傳統分層架構與 ORM 框架（如後續 NBear 篇將展示）。

實體類別就緒，下篇進入介面設計。