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

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 Framework на этот раз действительно помогает (хотя в книге много материала в стиле простых стилей Java, но снова в Redmond Wonderland).

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

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

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

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

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

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

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

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

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

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

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