[Как назвать] Имена классов и соотвествующих таблиц в БД
От: Аноним  
Дата: 11.08.11 10:44
Оценка: :)
Здравствуйте!
[C# 4.0]

Вот столкнулся с такой проблемой.
1. Есть такие сущности:
class Person
{
  Guid ID {get;set;}
  ...
}

class PersonConsumer
{
  Guid ID {get;set;}
  Guid PersonID {get;set;}
  ...
}

class PersonAccount
{
   Guid ID {get;set;}
   Guid PersonConsumerID {get;set;}
}

Физ.лицо, Потребитель Физ.лицо, Лицевой счёт физ.лица, соотвественно.

2. Тож же самое, но для юр.лиц:
class Organization
{
  Guid ID {get;set;}
  ...
}

class OrgConsumer
{
  Guid ID {get;set;}
  Guid OrgID {get;set;}
  ...
}

class OrgAccount
{
   Guid ID {get;set;}
   Guid OrgConsumerID {get;set;}
}

Есть ли какая-нибудь замена для более короткого обозначения PersonConsumer и OrgConsumer. Дело в том, что эти названия потом очень часто повторяются в названиях других классов и сущностей (н-р: PersonConsumerMeterReadingPaymentPurposeParams — вместо выделенного, есть ещё длиннее ), тем самым определяя принадлежность: к физ.лицу или к юр лицу.

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

Спасибо.
Re[3]: [Как назвать] Имена класов и соотвествующих таблиц в
От: Osaka  
Дата: 13.08.11 16:25
Оценка: +1
А>Вопрос по ходу, а как должен называться общий (абстрактный) Person?
Общая категория для физлица и юрлица это что-то типа "контрагент"
А>XxxxxxxZzzzzzzzzPaymentPurposeParams — в зависимости от услуги, могут быть разные квитанции на оплату, в которых могут быть разного вида параметры оплаты (PaymentPurposeParams)
Можно примеры? Не присутствует ли здесь антипаттерн "mixing data with metadata" (как например некоторые разбивают документы разных фирм по нескольким одинаковым таблицам с разными именами)?
Re: [Как назвать] Имена классов и соотвествующих таблиц в БД
От: Аноним  
Дата: 13.08.11 22:29
Оценка: +1
Здравствуйте, Аноним, Вы писали:

Разбираясь в подобном коде, я бы предпочел длинные и понятные названия коротким и непонятным.

А что вас смущает в длинных названиях? То, что никто обычно не делает длинных названий? или тяжело печатать? Если последнее, то поставьте себе "Resharper" — отличная вещь.

Я считаю, что во всем нужно руководствоваться логикой. Что из того, если все обычно не делают того, что в данном случае
целесообразно? Обычно не делают, потому что обычно такой потребности не возникает. Если у вас возникла объективная потребность сделать что-то, нерационально было бы отказываться от этого лишь из-за единственного аргумента "так обычно не делают".

Да вообще, честно говоря, когда я вижу код, в котором все сокращено, невольно возникает желание прибить автора этого творения. Длинные названия иногда труднее воспринимаются, если они очень длинные, но это все равно лучше, чем если бы они были непонятные.

Если название непонятное, то какая вообще к чертовой матери разница — длинное оно или короткое?

Да, и еще, мне кажется у вас в архитектуре присутствует некоторая нерациональность и дублирование. Если PersonConsumer и OrganizationConsumer оба являются потребителями (о чем намекает название), возможно, стоит выделить базовый класс Consumer, а если производные классы мало чем отличаются от базового, возможно стоит и оставить только класс Consumer, добавив свойство Type.
Re: [Как назвать] Имена класов и соотвествующих таблиц в БД
От: Osaka  
Дата: 12.08.11 14:23
Оценка:
А> полный формат вместе с namespace-ом, что не сильно-то облегчает чтение
А> кода.
На 1й взгляд, PaymentЧегототам должен быть одного типа для физ. и юр., и
ссылаться на абстрактного Person. Чем вызвано создание отдельных FizPayment
и UrPayment? У них есть какие-то разные атрибуты?
Posted via RSDN NNTP Server 2.1 beta
Re[2]: [Как назвать] Имена класов и соотвествующих таблиц в
От: Аноним  
Дата: 12.08.11 16:33
Оценка:
Здравствуйте, Osaka, Вы писали:
O>На 1й взгляд, PaymentЧегототам должен быть одного типа для физ. и юр., и
O>ссылаться на абстрактного Person.
Вопрос по ходу, а как должен называться общий (абстрактный) Person?

O>Чем вызвано создание отдельных FizPayment и UrPayment? У них есть какие-то разные атрибуты?

Разные виды и формы оплаты, и, соответственно, атрибуты.

XxxxxxxZzzzzzzzzPaymentPurposeParams — в зависимости от услуги, могут быть разные квитанции на оплату, в которых могут быть разного вида параметры оплаты (PaymentPurposeParams)
Re[4]: [Как назвать] Имена класов и соотвествующих таблиц в
От: Аноним  
Дата: 29.08.11 08:12
Оценка:
Здравствуйте, Osaka, Вы писали:

А>>Вопрос по ходу, а как должен называться общий (абстрактный) Person?

O>Общая категория для физлица и юрлица это что-то типа "контрагент"
Не совсем так. любое лицо может участвовать в работе системы. Для правильного учёта, не должно быть просто каких-то "лиц". Они все должны быть заведены в соответствующие справочники: физ. лицо или юр лицо. Далеко не всегда юр.лицо, например, будет участвовать в каких-либо договорных отношениях (например, какой нибудь орган исполнительный власти; работодатель плательщика, который должен быть сохранён в базе, но не обязательно участвуюйщий в учёте и т.п.

А>>XxxxxxxZzzzzzzzzPaymentPurposeParams — в зависимости от услуги, могут быть разные квитанции на оплату, в которых могут быть разного вида параметры оплаты (PaymentPurposeParams)

O>Можно примеры? Не присутствует ли здесь антипаттерн "mixing data with metadata" (как например некоторые разбивают документы разных фирм по нескольким одинаковым таблицам с разными именами)?
Нет, такого здесь точно нет. Да и примеров-то особо и нет — пока идёт набрасывание ObjectModel-и (очень много связанных объектов: unit-тесты только в ближайшей перпеспективе). Тут проблему разрешили по другому, ещё раз пересмотрели структуру платежа.

PS. Прошу прощения за, практически, некропост
Re[2]: [Как назвать] Имена классов и соотвествующих таблиц в
От: Аноним  
Дата: 29.08.11 08:17
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:


А>Разбираясь в подобном коде, я бы предпочел длинные и понятные названия коротким и непонятным.


А>А что вас смущает в длинных названиях? То, что никто обычно не делает длинных названий? или тяжело печатать? Если последнее, то поставьте себе "Resharper" — отличная вещь.


А>Я считаю, что во всем нужно руководствоваться логикой. Что из того, если все обычно не делают того, что в данном случае

А>целесообразно? Обычно не делают, потому что обычно такой потребности не возникает. Если у вас возникла объективная потребность сделать что-то, нерационально было бы отказываться от этого лишь из-за единственного аргумента "так обычно не делают".

А>Да вообще, честно говоря, когда я вижу код, в котором все сокращено, невольно возникает желание прибить автора этого творения. Длинные названия иногда труднее воспринимаются, если они очень длинные, но это все равно лучше, чем если бы они были непонятные.


А>Если название непонятное, то какая вообще к чертовой матери разница — длинное оно или короткое?


А>Да, и еще, мне кажется у вас в архитектуре присутствует некоторая нерациональность и дублирование. Если PersonConsumer и OrganizationConsumer оба являются потребителями (о чем намекает название), возможно, стоит выделить базовый класс Consumer, а если производные классы мало чем отличаются от базового, возможно стоит и оставить только класс Consumer, добавив свойство Type.

Спасибо! В принципе, так и думал. Правда сейчас, уже, добавли ещё один уровень абстракции: всё по гражданскому кодексу (в конце-концов, там не часто меняется вид субъектов) все делятся на физ.лиц и юр.лиц. А контрагенты разбиты на две группы: физ.лица и юр.лица (объяснения постом выше). А те уже, в свою очередь, разбиваются по видам. Мне кажется, так будет удобнее всем.
Re[3]: [Как назвать] Имена классов и соотвествующих таблиц в
От: Аноним  
Дата: 29.08.11 08:23
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Мне кажется, так будет удобнее всем.
Или я ошибаюсь
Re[3]: [Как назвать] Имена классов и соотвествующих таблиц в
От: Al_ Россия нпкинтегра.рф
Дата: 03.09.11 15:57
Оценка:
Здравствуйте, Аноним, Вы писали:

А>>Да, и еще, мне кажется у вас в архитектуре присутствует некоторая нерациональность и дублирование. Если PersonConsumer и OrganizationConsumer оба являются потребителями (о чем намекает название), возможно, стоит выделить базовый класс Consumer, а если производные классы мало чем отличаются от базового, возможно стоит и оставить только класс Consumer, добавив свойство Type.

А>Спасибо! В принципе, так и думал. Правда сейчас, уже, добавли ещё один уровень абстракции: всё по гражданскому кодексу (в конце-концов, там не часто меняется вид субъектов) все делятся на физ.лиц и юр.лиц. А контрагенты разбиты на две группы: физ.лица и юр.лица (объяснения постом выше). А те уже, в свою очередь, разбиваются по видам. Мне кажется, так будет удобнее всем.
Это тоже самое, что тебе хотел сказать Osaka: "mixing data with metadata".
Автоматизация.ERP
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.