命名約定和命名空間

Question

如果我在一個圖層上有與另一個圖層上的對象同名的對象，最好是用一些前綴更改對象名稱還是使用新的命名空間並用完全限定的名稱引用它們？ 例如：

namespace Project1.Data
Object Person;

namespace Project1.Model
Object Person;

---

Data.Person.Name=Person.Name;

OR

dbPerson.Name= Person.Name;

Answer 1

我使用命名空間和命名空間別名，例如：

在適當的命名空間中定義類：

namespace Project1.Data
{
    public class Person {...}
}
namespace Project1.Model
{
    public class Person {...}
}

在使用類的地方，要么使用完全限定名稱，要么為命名空間定義別名（如果完整命名空間很長，則使用usefule）：

using data = Project1.Data;
using model = Project1.Model;

data.Person p1 = new data.Person();
model.Person p2 = new model.Person();
//...
p1.Name = p2.Name;

Answer 2

這取決於您引用重載名稱的頻率。

如果您在一個文件中多次使用它，請使用第一種方式。

如果您只使用它一次或兩次，那么請寫出完全限定的名稱，這樣其他人就不必在文件頂部狩獵來找出您所指的對象。

Answer 3

這實際上取決於您要求每個人的頻率。 一般來說，我使用的縮寫版本最常用於我所指的類型，並且對於不常使用的類型使用較長的名稱。 我最后會說，如果你最終在同一個文件中有很多用法，你應該使用命名空間別名，但對我而言，只有在代碼膨脹到難以達到的程度之后，這才是最后的手段。跟着發生了什么。

Answer 4

有同樣的想法自己。 我認為查找類的名稱是一個壞主意。 例如，我有一個數據訪問層和一個業務層。 兩者都與用戶打交道。 所以我有...

Project1.Business.User Project1.DataAccess.User

試圖想出這些類的創造性新名稱是浪費時間，並且可能意味着對於沒有意義的類的奇怪名稱。 命名類已經足夠令人頭痛。

我同意McWafflestix“我使用的縮寫版本最常用於我所指的類型，並且使用較長名稱的類型較少使用”。

Answer 5

這很簡單。 一次聽.NET框架指南實際上有所幫助（盡管本書中的大量內容只是Java風格的簡單元素，但在Redmond Wonderland中再次出現）

您應該避免在交叉或項目內/庫混合命名空間中使用類似的類型名稱，即。 跨域和模型混合（即使在C ++中極其嚴格和強大，它也有編譯器，解決方案和枚舉式編譯器崩潰和問題的化身）。

因此，即使完全符合條件也不是萬無一失（btw別名和'使用'是極其有限的，並且最好導致輕微的重復，以及證明通用編程中的C＃弱點等）。

根據我的經驗，數據域類型是更合適的名稱的主要目標，因此對於名稱重構，它是：

a）便宜（作為豐富的AST中的過程，但在C＃中提供簡單的adt-s支持，在IDE中右鍵單擊並根據類型挑戰的動態Ruby粉絲/支持者感覺強大）

[也可以理解為：4.0動態功能綿羊會責怪每個人但不考慮名稱空間或功能JS，C模板（不是C-with-classes）或類似的]

b）更好地傳達語義，即。 意圖（即管道+支持構建自己的處理）

c）通常具有原始但有類型的性質或信息（不是OO類型;即OO風格的批評，如前面提到的那本書直接突破介紹所有“模型”引用土地）

d）和'別名'在跨域使用中成為一個有用的工件（這實際上是可能的，並且非常像2020年......即價值型編程）

確實沒有規則，但要注意你會在最不期望的時候看到開發中名稱空間的混合......這意味着對於一個有管理意識的開發人員來說只有一件事：混亂。 加上稍微不那么嚴重，更多編譯時和IntelliNonsense錯誤當然..

所有語言都存在嚴峻的問題，因此這是您的設計/命名問題。甚至工具供應商也可以搞砸機器來解析...說基於過時瀏覽信息的增強型流行IDE的輸出; 然后，其他人對托管語言做得很好。

並不是說我反對復制名稱，有些情況（它們很難但很必要）混合雙+互操作+表示等其他模型，其中相同的名稱使其更具可讀性; 即。 復制是雙重用法的必要性..但這是C＃不友好或不鼓勵的低級習語（re：贊成開銷）。