Переименование класса другой сборки

Uswer · Регистрация: 26.06.2017

Студворк — интернет-сервис помощи студентам

Добрый день.

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

C#
1
2
3
4
5
class User
{
  public string Name {get;set;}
  public int Age {get;set;}
}

Также в подключаемой сборке есть классы оперирующие классом User, например сервисы, которые возвращают объекты класса User.
Мне хотелось бы работать с классом User в сборке именованным, например как UserDto, а класс User определить в разрабатываемом приложении и маппить их друг в друга. То есть в своём приложении определить класс:

C#
1
2
3
4
5
class User 
{
  public string UserName {get;set;}
  public int UserAge {get;set;}
}

Подскажите как можно решить проблему переименования?

@IamRain · 16.02.2024, 18:54

Сообщение от HF

Основное обсуждение - "автодетектирование" одноимённых моделей.

Тут я не дискутирую, делал бы через алиасы да и пойдет; Пост выше - это ответ на

Сообщение от Wolfdp

Менее гибкий вариант в виду того, что одна модель теперь знает о существовании другой. Extension можно подключать отдельным модулем.

Сообщение от Wolfdp

в пухель их. Один из самых противных кактусов, который приходится жевать

И на вашу просьбу уточнить.

@HF · 16.02.2024, 18:59

Сообщение от IamRain

Отсылочка к high cohesion.

А этот вывод только опять запутал. К какому примеру это применимо. То что Map метод не понятно где? В сервисе если, это плохо?
А второй вариант - это "близко"? ну там как я сказал уже - вообще до метода добраться надо ещё. И он по сути от маппинга ничем не отличается. Зато вот если вы вдруг начнёте генериками пользоваться, то вот тут можно "отхватить" при такой конвертации разного. А явный метод - он явный метод.

Добавлено через 5 минут

Сообщение от IamRain

Тут я не дискутирую, делал бы через алиасы да и пойдет; Пост выше - это ответ на

Перечитал его пример. Помоему он как раз и сказал, что теперь в проекте нужно будет "знать" про обе модели, что плохо. И что внешний сервис хотя бы снимает эту необходимость. Вроде всё понятно.
А вы умные слова про императив. Я не понял.

@IamRain · 16.02.2024, 19:12

Сообщение от HF

Помоему он как раз и сказал, что теперь в проекте нужно будет "знать" про обе модели, что плохо.

HF, блин, какой вы сложный.

Это был side note

Можно еще для разнообразия переопределить explicit operator

И вся остальная аргументация - ответ на замечания от Wolfdp.

Uswer · 16.02.2024, 19:29 **[ТС]**

Сообщение от HF

Помоему он как раз и сказал, что теперь в проекте нужно будет "знать" про обе модели, что плохо.

Я тут запутался, но если речь про мой пост, то я поступил так: всю логику работы с namespaceA.User засунул в промежуточный класс, методы которого возвращают во внешний код (код приложения) объекты аля applicationnamespace.OterUser. И всё, путаницы нет, на уровне приложения только один вид сущностей.

@Wolfdp · 16.02.2024, 22:16

Не по теме:

Сообщение от Uswer

Я тут запутался, но если речь про мой пост

Не, дискуссия явно рванула дальше.

@Usaga · 17.02.2024, 05:01

Сообщение от Wolfdp

в пухель их. Один из самых противных кактусов, который приходится жевать. Может не для БД моделей это и имеет оправдание (для всяких объектов состояния). А так приходится держать в уме логику поведения модели, что ну прям не всегда найс.

Так это и не про БД ни разу. Надо же понимать какие модели делать rich'ёвыми. Если для тебя это был кактус, то тут одно из двух: или логику не в ту модель засунули, или что-то второе. Я понимаю твоё недовольство, ибо сам видел такой кактус часто. Когда новички начинали играться с DDD и первое что они делали - начинали видеть в сущностях EF'а бизнес-модели, со всеми отовсюду вытекающими последствиями. Это не проблема рич моделей, это - проблема программиста, который делает фигню)

Сообщение от HF

Ну дак да, компилятор то поможет. Но весь сыр бор чтобы и затупов не было.
Ну вот у меня часто бывают ситуации. Вызваю метод, вставляю параметр Юзер. А оно говорит "Какой именно Юзер? у вас амбициозиус неймспейс для этой модели. И вот тут я должен пойти и протыкивать чтобы понять а что мне дейсвительно нужно. И потом я ещё часто остаюсь в сомнениях - а всё-таки мне точно именно этот юзер нужен был? вдруг и метод не тот. А если б, например, было Юзер, ЮзерДто и ЮзерВьюмодель, я б даже не сомневался.

Я исхожу из своего опыта работы над крупным проектом. У нас тоже сначала были ЮзерДто, ЮзерВьюМодель и тому подобное. А потом приложение начало делиться на логические контексты и начали появляться ЮзерАрестЭкспортМичиганДто, ЮзерСетапВритеМодель и т.д. Названия начали неумещаться в ширину экрана) Да, оно видно сразу, что это, но блин... В общем, не могу сказать какой подход тут супер правильный. Но мы для себя решили совмещать префиксы-суффиксы в именах и пространства имён: МичиганАрестЭкспорт.ЮзерДто. Вне сборки имя нужно использовать полное, внутри - можно сокращённое. Так у нас баланс получился между очевидностью и избыточностью имен.

@Wolfdp · 17.02.2024, 06:03

Не по теме:

Сообщение от Usaga

Так это и не про БД ни разу.

Да, но у меня последнию неделю горит от всего и вся касаемо кода, так что няфиг объективость -- сказал в пухель, значит там им и место!

По идеи как-то надо угадать с тем, что из себя должна представлять модель. БД, всякие контракты API, message, вычитуемые конфиги из файла -- по идеи всё это добро должно тупо содержать данные и не более. Ну может рассчетные свойства, которые исключительно по внутренним полям/свойствам возвращают значения.

Rich модель -- это уже что-то имеющее внутренне состояние: чешешь её в одном месте, меняется в другом и ещё ивентам пинается. По идеи это всякие контексты, сессии... И всё равно с ними стоит аккуратней. Всё что выносится наружу -- выкидываем. Затащить его внутырь как правило не проблема, а вот выкорчивать -- то ещё приключение.

@Usaga · 17.02.2024, 06:28

Сообщение от Wolfdp

БД, всякие контракты API, message, вычитуемые конфиги из файла -- по идеи всё это добро должно тупо содержать данные и не более.

Абсолютно верно. Это всё DTO'шки разнородные.

Сообщение от Wolfdp

Rich модель -- это уже что-то имеющее внутренне состояние: чешешь её в одном месте, меняется в другом и ещё ивентам пинается.

Про место и ивенты я не совсем понял. Рич-модель - это уже кусочек предметной области, с состоянием и логикой. Не везде и не всегда нужно. Но при грамотном применении очень сильно наглядность и выразительность кода повышает, без каких-то трейдофов. Ополчаться на это не стоит. А вот научиться пользоваться - однозначно. Меня на прошлом проекте ну очень часто оно выручало, когда надо было воротить много бизнес-логики. Тут главное не впадать в крайности. Не использовать совсем или пихать везде и всюду - одинаково не правильно.

Новые блоги и статьи Все статьи Все блоги /
Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .