linq2db и enum MapValue без использования MapValue

@BeginnerCoderCS · Регистрация: 10.01.2020

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

Добрый день!

В этой теме касались enum Архитектура построения БД linq2db но ответа на мой вопрос там нет.

Есть класс таблицы БД MySQL

C#
1
2
3
4
5
6
    
    public class MyTable
    {
        [PrimaryKey, Identity] public int Id { get; set; }
        [Column, NotNull] public Status? Status { get; set; }
    }

Есть enum с MapValue

C#
1
2
3
4
5
    public enum Status
    {
        [MapValue(Value = "OFF")] OFF = 0,
        [MapValue(Value = "ON")] ON = 1,
    }

Таблица создаётся так, что значение Status это int

SQL
1
2
3
4
5
CREATE TABLE `MyTable` (
    `Id` INT NOT NULL AUTO_INCREMENT,
    `Status` INT(11) NOT NULL DEFAULT '-1',
    PRIMARY KEY (`Id`)
);

Так как в enum указаны MapValue то linq2db пытается получать тексты из MapValue, а мне нужны значения int = 0 а не "OFF"

Можно создать дубль enum без MapValue, но enum несколько десятков значений, и не хотелось бы дублировать.

Добавление типа int в класс MyTable DataType(LinqToDB.DataType.Int32) ничего не даёт.

C#
1
2
3
4
5
public class MyTable
    {
        [PrimaryKey, Identity] public int Id { get; set; }
        [Column, NotNull, DataType(LinqToDB.DataType.Int32)] public Status? Status { get; set; }
    }

Подскажите как лучше выйти из этого положения?

@MsGuns · 24.10.2021, 18:50

Катафалк, Если написать классы-модели + класс-репозитрий, в котором на "голом SQL" реализовать всю работу с БД (выборки, апдейты, инсерты и проч.) и весь функционал приложения свести к простым обращениям к репозиторию, обмениваясь с ним моделями - будет ли это, по Вашему мнению, "ORM" или нет ?

@HF · 25.10.2021, 00:25

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

А он точно адекватный, этот заказчик? Обычно, когда людям нужно понимать что за перечисления в таблице, то заводят вторую таблицу (статический справочник) с текстовыми представлениями значений перечисления и делают внешний ключ на неё. Всё. Если заказчику нужно увидеть, что означают все эти 0, 1, 2... 100500, то он просто делает JOIN к справочнику.

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

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

это желание заказчика, где ему нужно видеть зрително статусы в самой БД.

Видать кто-то в БД лазит всё ещё, тем же Access например, ну или "обученные юзеры" с доступом в БД умеющие запустить MSSMS и выполнить нужный запрос (и такое у меня в практике было не мало).
Кстати во второй случае ещё проще - нужно написать обновлённый запрос с JOIN и у них ничего на экране не изменится. А программисту лишняя проблема.

@Usaga · 25.10.2021, 08:25

Сообщение от Катафалк

Совет выкинуть ОРМ из проекта не может быть мимо кассы, точно так же как и совет не удалять гланды через задний проход, если кто-то собирается такое сделать

Откуда взялась мысль о том, что ОРМ в проекте вещь лишняя и аналогичная операции через задницу? Аргументировать можете?

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

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

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

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

Вся данная тема и родилась из-за этой чертавни с перечислениями)

@Катафалк · 25.10.2021, 09:10

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

Если написать классы-модели + класс-репозитрий, в котором на "голом SQL" реализовать всю работу с БД (выборки, апдейты, инсерты и проч.) и весь функционал приложения свести к простым обращениям к репозиторию, обмениваясь с ним моделями - будет ли это, по Вашему мнению, "ORM" или нет ?

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

Сообщение от Катафалк

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

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

Откуда взялась мысль о том, что ОРМ в проекте вещь лишняя и аналогичная операции через задницу? Аргументировать можете?

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

@Andrey-MSK · 25.10.2021, 09:16

Сообщение от Катафалк

SQL называется.

А кто мешает для простых целей использовать ORM, и для более сложных голый ADO .NET? И всё это в одном проекте. Чего тут сложного? На ORM повесить простенькие SELECT, UPDATE, DELETE, а если что посложнее, то уже писать через SqlCommand. Всё прекрасно уживается в одном проекте и даже спокойно общается через одни классы данных.

@Катафалк · 25.10.2021, 09:20

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

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

Как раз наоборот, это отказ от человекочитаемости хранилища должен серьезно обосновываться. То, что вебокодер не может натянуть требования на его убогий ОРМ обоснованием не является, естественно.

Сообщение от Andrey-MSK

А кто мешает для простых целей использовать ORM, и для более сложных голый ADO .NET?

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

@Andrey-MSK · 25.10.2021, 09:23

Сообщение от Катафалк

для упрощения сложных взаимодействий с БД,

Не для этого они задумывались, а для упрощения написания рутинного взаимодействия с БД. Это уже потом в них начали пихать всё что надо и не надо

@MsGuns · 25.10.2021, 15:23

Сообщение от Катафалк

Зачем вы пытаетесь увести тему туда, где она уже была и ответ был дан?

Ничего и никуда я не пытался "увести".
Если все Ваши выпады в сторону ORM касаются монстров типа EF, который часто действительно тащит много лишнего, ресурсоемок и вообще неуклюж, то я с Вами не спорю, т.к. согласен. Помню, как выбешивало то, что он наотрез отказывался правильно интерпретировать в классы НД, возвращаемые хранимками и приходилось буквально извращаться в коде SP для того, чтобы он правильно понял, что оттуда выгребается.
Однако в плане "экономичности" кода с учетом того, что далеко не все программисты свободно "разговаривают" на SQL, EF имеет право на жизнь. Хотя, конечно, использовать его нужно с умом.

@Usaga · 25.10.2021, 17:06

Сообщение от Катафалк

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

Можете локализовать этот вред? В чём он выражается? Так-то, ОРМ и создаются для автоматизации рутинных задач писанины тонны SQL. В грамотных руках они с этим справляются.

Сообщение от Катафалк

Как раз наоборот, это отказ от человекочитаемости хранилища должен серьезно обосновываться. То, что вебокодер не может натянуть требования на его убогий ОРМ обоснованием не является, естественно.

Т.е как это отказ от человекочитаемости? Код на том же LINQ существенно короче. Плюс, можно ещё и переиспользовать куски выражений. А что вы мне про динамические запросы расскажите? Они руками тоже более читаемые составляются?)))

Сообщение от Катафалк

Там где нужен простой запрос, нет никаких проблем написать его руками.

Только реальные приложения нифига не про простой запрос.

@Катафалк · 25.10.2021, 17:13

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

Можете локализовать этот вред? В чём он выражается? Так-то, ОРМ и создаются для автоматизации рутинных задач писанины тонны SQL. В грамотных руках они с этим справляются.

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

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

Т.е как это отказ от человекочитаемости?

Речь о человекочитаемости храналища. А LINQ ОРМ, следовательно - на помойку

И динамические запросы тоже - ручками.

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

Только реальные приложения нифига не про простой запрос.

Ага, о том и речь. Там, где ОРМ может быть полезен - он не нужен. А там, где по задумке его создателей нужен - не полезен, а совсем наоборот.

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

Однако в плане "экономичности" кода с учетом того, что далеко не все программисты свободно "разговаривают" на SQL, EF имеет право на жизнь. Хотя, конечно, использовать его нужно с умом.

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

@Usaga · 25.10.2021, 17:16

Сообщение от Катафалк

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

Расскажите мне про ограничения Linq2Db. Они есть, да, но я хотел бы от вас услышать какие именно и на что они влияют.

Сообщение от Катафалк

Речь о человекочитаемости храналища. А LINQ ОРМ, следовательно - на помойку И динамические запросы тоже - ручками.

Так эта человекочитаемость улучшается. Это основная цель создания ORM.

Сообщение от Катафалк

Ага, о том и речь. Там, где ОРМ может быть полезен - он не нужен. А там, где по задумке его создателей нужен - не полезен, а совсем наоборот.

Пример приведёте?

Сообщение от Катафалк

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

Где связь между уровнем квалификации и применением ORM?

@Катафалк · 25.10.2021, 17:26

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

Расскажите мне про ограничения Linq2Db. Они есть, да, но я хотел бы от вас услышать какие именно и на что они влияют.

Понятия не имею, я этот ваш сишарп с linq2db только на картинках видел

Это как раз вам и вопрос, раз вы типа специалист. Вангую, что в любых более менее сложных случаях сгенерированные им запросы можно смело выкинуть в помойку - это в принципе свойство любого ОРМа. Если, конечно, такие запросы на нем в принципе можно написать.

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

Так эта человекочитаемость улучшается. Это основная цель создания ORM.

Основная цель создания ОРМа - дать возможность веберам, неспособным осилить SQL, работать с БД. Больше они ни для его непригодны. И уж точно они не имеют никакого отношения к человекочитаемости хранилища.

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

Пример приведёте?

Выше в теме объяснено о чем речь, по моему даже 2 раза. Не ленитесь прочитать, на что отвечаете.

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

Где связь между уровнем квалификации и применением ORM?

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

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

Однако в плане "экономичности" кода с учетом того, что далеко не все программисты свободно "разговаривают" на SQL, EF имеет право на жизнь.

@MsGuns · 25.10.2021, 17:42

Дискуссия зашла в тупик

Есть большой любитель лошадей, телег и карет. Ну как же, нет нужды в бензине, масле, не нужно никаких СТО и ПДД.
Вот только карет почему-то на дорогах не видно. Как и телег.
Но коневоду на это плевать - ну нравиться ему вдыхать аромат конского навоза

А еще ему нравится троллить всех автомобилистов, призывая повально переходить на конную тягу.

@BeginnerCoderCS · 25.10.2021, 18:32 **[ТС]**

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

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

@Катафалк · 25.10.2021, 19:08

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

Есть большой любитель лошадей, телег и карет. Ну как же, нет нужды в бензине, масле, не нужно никаких СТО и ПДД.

Это SQL для вас телега?

Новые блоги и статьи Все статьи Все блоги /
20. Мат мед. Абсентеизм как отдельный тип простоя anaschu 29.05.2026 Апдейт модели: исправленные баги, абсентеизм и новые механизмы Продолжаю развивать ранее описанную модель рабочего коллектива на AnyLogic. За последние несколько дней был проведён серьёзный. . .	19. здоровье, усталость и психотип работника влияют на производительность предприятия, и наоборот, производительность на здоровье, усталось и психотип anaschu 28.05.2026 Дискретно-событийная модель рабочего коллектива на AnyLogic: здоровье, выгорание, психотипы и микростимуляция Привет, коллеги. Хочу поделиться итогами нескольких недель работы над симуляционной. . .	"Прокси" для последовательного порта Eddy_Em 28.05.2026 Эту штуку написал я достаточно давно. Но сейчас вот понадобилось настроить датчик грозы, но при этом не отключать его от "метеодемона". Соответственно, надо запустить этот "прокси": метеодемон будет. . .	Рефакторинг программы уравнивания. Massaraksh7 26.05.2026 Пример по предыдущей записи в блоге. Но, надо заметить, что, во-первых, там оптимизация не только математики, но и работы с базой данных, и с графами, а во-вторых, это ещё не всё.
Использование TThread в Lazarus для математических вычислений. Massaraksh7 25.05.2026 Производя рефакторинг своих программ на предмет ускорения их работы, обратил внимание на такой аспект, как сокращение времени матвычислений. Дело в том, что приходится работать с большими матрицами. . .	Модель здравосохранения 18. Чем здоровее работник, тем быстрее выгорает anaschu 24.05.2026 Имитационная модель корпоративного здравоохранения: что показывает математика Сегодня в модели рабочего коллектива на AnyLogic появились три новые механики — выгорание через накопленную усталость,. . .	Модель здравосохранения 17. Планы на выгорание anaschu 23.05.2026 Вот конкретная схема реализации: В классе Работник добавить: накопленнаяУсталость — растёт каждый час работы, снижается в перерывы и болезни коэффициентПрезентеизма — снижает продуктивность. . .	Изменение цветов в палитре gif файла aka фавикона russiannick 23.05.2026 Изменение цветов в палитре gif файла, юзаемого как фавиконка в составе html-файла, помещенная в base64, средствами нативного Java Script, навеянное сном в майский день. Для работы необходим браузер,. . .

@MsGuns 1497 / 1238 / 245 Регистрация: 04.04.2011 Сообщений: 4,363
	24.10.2021, 18:50
	Катафалк, Если написать классы-модели + класс-репозитрий, в котором на "голом SQL" реализовать всю работу с БД (выборки, апдейты, инсерты и проч.) и весь функционал приложения свести к простым обращениям к репозиторию, обмениваясь с ним моделями - будет ли это, по Вашему мнению, "ORM" или нет ? 0

@MsGuns 1497 / 1238 / 245 Регистрация: 04.04.2011 Сообщений: 4,363
	25.10.2021, 17:42
	Дискуссия зашла в тупик Есть большой любитель лошадей, телег и карет. Ну как же, нет нужды в бензине, масле, не нужно никаких СТО и ПДД. Вот только карет почему-то на дорогах не видно. Как и телег. Но коневоду на это плевать - ну нравиться ему вдыхать аромат конского навоза А еще ему нравится троллить всех автомобилистов, призывая повально переходить на конную тягу. 0