單一職責是降低耦合度的指導思想，適用于一個微服務，一個類型，一個方法。

微服務層：

微服務一般按業務的領域來進行拆分：藥房微服務就是藥房的業務，護士站微服務就是護士站的業務，廣義上沒有什么問題，但對于一些共用業務，就犯難了，究竟放在那個微服務里？還是合并兩個微服務？其實這里就單一，把共用的抽離出來，不一定做成另一個微服務，可以統一做成類庫，供兩個微服務調用，如果業務有細微差別，可以通過設計模式來靈活解決異構情況。

類型：

這里的類型，一般指復雜類型：如結構體(struct)，接口(interface)，抽類(abstract class)，實例化類(class)，記錄(record)。這此類型內部，重要的成員有屬性，方法，正是這些成員的規劃，是決定這些類型是否職責單一的重要指標。

比如下面的用戶類型，這樣的定義是不沒有錯誤的，對于一些小型項目，這樣定義是最經濟的。

/// <summary>/// 用戶/// </summary>class User{/// <summary>/// 用戶名 /// </summary>public string UserName { get; set; }/// <summary>/// 密碼/// </summary>public string Password { get; set; }/// <summary>/// 性名/// </summary>public string Name { get; set; }/// <summary>/// 性別 true男，false為女/// </summary>public bool Sex { get; set; }/// <summary>/// 職務/// </summary>public string Position { get; set; }/// <summary>/// 生日/// </summary>public DateTime Birthday { get; set; }}

如果從單一職責考慮，這個類可以分為三個類，如下：

/// <summary>/// 用戶/// </summary>class User{/// <summary>/// 用戶名 /// </summary>public string UserName { get; set; }/// <summary>/// 密碼/// </summary>public string Password { get; set; }}/// <summary>/// 人員職務/// </summary>class Position{/// <summary>/// 職務名稱/// </summary>public string PositionName { get; set; }}/// <summary>/// 人員/// </summary>class Person{/// <summary>/// 人員編號/// </summary>public string PersonNo { get; set; }/// <summary>/// 性名/// </summary>public string Name { get; set; }/// <summary>/// 性別 true男，false為女/// </summary>public bool Sex { get; set; }/// <summary>/// 年齡/// </summary>public int Age { get; set; }/// <summary>/// 用戶/// </summary>public User User { get; set; }/// <summary>/// 職務/// </summary>public Position[] Positions { get; set; }}

分開以后，雖然代碼增多了，但每個類的作用就單一了，用戶就是用戶，人員就是人員，職務分出來當其擴展時其他類型也不受影響。

方法：

越往下層，單一職責的把握越困難，特別是在寫一個方法的時候，單一的這個單位很模糊，怎么就算單一？

比如寫一個發送數據模塊，主要分部分：組織數據，發送數據，也就對應兩個方法BuildData,SendData，可能在組織數據時發現，有些數據得作轉換，比如時間，類型等，這時可以在BuildData里作轉換，當然也可以把轉換這部分抽離出來，組成一個TransformData，糾結的是，有時轉換數據只要一行代碼，如果按單一職責思想應該分離出來，但看到分離的代碼覺得差強人意，有沒有一個標準呢？

這里我給出我自己的標準（僅代表自己的認識）：

1、在糾結一個方法要不要拆開時，第一考慮是業務的單一性

2、有些業務之間當前狀態統一的，要聯想下一步狀態，或下一階段，這種狀態是否持續(不要關心這個狀態在現實中什么時間到來)

3、多用一些經典的設計模式來讓方法彼此隔離，互不干擾

總結

以上是生活随笔為你收集整理的单一职责在.NET中的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。