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 для вас телега?

Новые блоги и статьи Все статьи Все блоги /
Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .	Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .
Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .

@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