任意の命名規則 (ビジネスオブジェクト)

Question

わかりました、そうしますか Business.Name または Business.BusinessName SubCategory.ID または SubCategory.SubCategoryID

データベースではどうでしょうか?

なぜ？

私は両方に引き裂かれました。「正解」があればいいのですが

Answer 1

ID、名前などを使用する主な欠点は、2 つのテーブルに重複する SQL 結合を作成する場合、それらをテーブル名で修飾する必要があることです。

それにもかかわらず、ID と名前だけを使用する方がはるかに簡潔で読みやすいと思います。コードとテーブルが目に見えずに「流れる」ことがはるかに簡単になります。入力が簡単になり、冗長性が減ります。そして「SELECT Business.Name FROM ...」と入力します。SQL クエリで SELECT BusinessName FROM ... と入力することほど面倒なことはありません。

一般に、意味情報を繰り返していることに気付いた場合、それを排除する方法を探すか、少なくともそれが繰り返される理由を認識するように警告します。これは、小規模 (属性名) の場合もあれば、大規模 (動作パターンや共通のクラス構造) の場合もあります。

Answer 2

唯一の「正しい」答えは、一貫性を保つことです。プロジェクトでどれを使用するかを事前に決定し、それを守ります。

Answer 3

「名前」や「ID」などの非常に一般的なプロパティの場合、私が使用した規則は、フィールドにエンティティ名を入力しないことです。さらに珍しいプロパティについては、エンティティ名を入れます。

これは命名規則による決定ですが、この規則に従って各 ID にエンティティの名前を入力すると、冗長すぎるように見えるプロジェクトを後悔したことはありません。

Answer 4

主キーであるあらゆるものに対して ID を実行します。SubCategory.SubCategoryID と言うのは冗長に思えますが、

Answer 5

正しくないかもしれませんが、イドの方が美味しいと思います。

もの.id
なぜなら、オブジェクトを処理し、主キーが必要なリフレクティブなものを作成する場合、どこでも主キーを知ることができ、式でそれを決定しようとする方が簡単だからです。

もう 1 つに関しては、これは完全な好みであり、他の文字を入力するのに時間が無駄になること以外に実際の影響は見当たりません。また、その .net では実際に名前空間を入力する人はいません。