Соглашения об именах и пространства имен

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

Все просто. Слушание руководящих принципов .NET Framework на самом деле действительно помогает (хотя большое количество материала в книге - просто простые элементы стиля Java И снова в Редмондской стране чудес) ..

Вам следует избегать похожих имен типов в пространствах имен смешанного или внутрипроектного / библиотечного смешивания, т.е. смешивание между доменами и моделями в generial (даже в C ++, который является чрезвычайно строгим и мощным, он также имеет воплощение сбоев и проблем компилятора, разрешения и перечисления в стиле enum).

Поэтому даже полная квалификация все время не является надежной (и, кстати, псевдонимы и «использование» чрезвычайно ограничены и в лучшем случае вызывают слабое дублирование, а также доказывают слабость C # в универсальном программировании и т. Д.).

По моему опыту, типы предметных областей являются основной целью для более подходящего имени и, следовательно, для рефакторинга имени, которое:

a) дешево (как процесс в богатых AST, но с простой поддержкой adt-s, как в C #, щелкните правой кнопкой мыши в IDE и почувствуйте себя мощным в соответствии с динамическими поклонниками / покровителями Ruby))

[также может быть прочитано как: 4.0 динамические функции, овцы будут винить всех, но не будут думать о пространствах имен или функциональных JS, шаблонах C-with (не C-with-classes) или подобных)

б) лучше передает семантику т.е. намерение (т. е. слесарное дело + поддержка для создания собственной обработки)

c) обычно имеет примитивную, но типизированную природу или сообщение (набирается не OO; т.е. критика в стиле OO, как в вышеупомянутой книге, которая сама по себе выходит из вступления, поднимает все «Модели» на эталонную землю)

d) и «псевдонимы» становятся полезным артефактом в междоменном использовании (что на самом деле возможно и весьма похоже на 2020 год… т.е. программирование типа значения)

На самом деле нет никаких правил, но имейте в виду, что вы увидите смешивание пространств имен в процессе разработки, когда они менее всего ожидаемы ... что означает только одно для управляемого разработчика: замешательство. Плюс несколько менее серьезные, больше ошибок времени компиляции и IntelliNonsense, конечно ..

Сложная проблема на всех языках, так что это проблема вашего дизайна / наименования. Даже поставщики инструментов могут испортить машины для анализа ... скажем, вывод расширенных популярных IDE на основе устаревшей информации о просмотрах; опять же, другие делают это очень хорошо для управляемых языков.

Не то чтобы я против дублирования имен, бывают случаи (они жесткие, но необходимые), когда смешиваются двойное + взаимодействие + представление и т. Д. Другие модели, где одно имя делает его более читабельным; то есть. где дублирование является необходимостью двойного использования ... но это идиомы более низкого уровня, которые C # не дружественен или не поощряет (в отношении накладных расходов).

Answer 4

Я тоже думал об этом. Я думаю, что изменение названия классов - плохая идея. Например, у меня есть уровень доступа к данным и бизнес-уровень. Оба имеют дело с пользователями. Итак, у меня есть ...

Project1.Business.User Project1.DataAccess.User

Попытка придумать новые изобретательные имена для классов - пустая трата времени и, вероятно, будет означать нечетные имена для классов с небольшим значением. Имена классов уже могут быть достаточно головной болью.

Я согласен с McWafflestix: «Я использую сокращенную версию для типа, на который я ссылаюсь чаще всего, и использую более длинное имя для типа, который используется реже».

Answer 5

Это действительно зависит от частоты, которую вы запрашиваете у каждого из них. Как правило, я использую сокращенную версию для типа, к которому я обращаюсь чаще всего, и использую более длинное имя для типа, который используется реже. В конце концов, я бы сказал, что если вы в конечном итоге будете использовать много раз в одном и том же файле, вам следует использовать псевдонимы пространства имен, но для меня это последнее средство только после того, как код раздулся до точки, где трудно следите за тем, что происходит.