qwerartem,

https://csharp-station.com/Article/Index/StronglyTypedDatasets

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

т.е. вместо
string orderID = dsOrders.Orders[0].OrderID;

было бы​
TOrderID orderID = dsOrders.Orders.FirstRow.OrderID;

Реализацию правда делал только для ключей.

Petro123,

потом пришел ОРМ например в виде EF и сделал это.
-----
Увы, но не сделал. По крайней мере Я не видел.
Если видел - покажи, плс, где...

Petro123,

Оно?
-----
Не-а...
Непонятно почему ты посчитал значение типизированной строки значением типизированного поля...

Petro123,

переведи.
Ты лучше скажи чем тебе типизация ОРМ не устраивает.
-----
​Так тебе перевести или что-то пояснить?

TOrderID orderID = контекст.Orders. FirstOrDefault()
vs
TOrderID orderID = dsOrders.Orders. FirstRow.OrderID ;

- FirstOrDefault() - относительно Orders дает объект из коллекции Orders или поставляет пустышку.

TOrderID, однако, не предполагает иметь строку, но ожидает ПК первой строки (или ехцептион если ее нет, но об этом ты не знаешь, не важно)

Чтобы было понятнее зачем такой изврат... хммм... назову две вещи:
- чтобы можно было ФК присвоить значение ПК, но не наоборот и ошибка была при компиляции
- чтобы поддерживать две версии проекта, в котором один ТОредерИД представляется 10-ти байтным целым, а в другом - 16-ти байтным целым...

И тоже самое желаю иметь по всем остальным полям.

НУ и как там с называнием ОРМа который это умеет?

Petro123,

я и написал чтобы
-----
Ты написал просто ДРУГОЕ. То, что может сделать маппер.
И почему-то уперся и не рассматриваешь другие возможности.


маппинг модели отслеживает.
-----
Пыхх...
Ну ладно - вот текучка:
public void Load(string pBatchNo, string pOrderNo = null, string pItemNo = null)

Мне нужна ошибка при компиляции, если я вместо

string batchNo​

случайно подставлю

string orderNo​

Бо, в форме аккурат поиск по обоим полям.

Т.е. Я хочу
public void Load(TBatchNo pBatchNo, TOrderNo pOrderNo = null, TItemNo pItemNo = null)


вообще нет разговоров о байтах.
-----
Не проблема - опускаем Binary(n)
и делаем композитный ключ - целое, строка(40) еще целое и еще целое. Ну и чтобы весело стало - еще и поле моней-типа добавим.
Чтобы оно там не было, в коде Я хочу его видеть, как TOrderID тип.

Petro123,

Если ты про райзе, то у First() будет райзе.
-----
Не понял терминологию.
Мне надо, чтобы типизированными были не только объекты в коллекции, но и поля в объектах.
И при этом крайне желательно без большого оверхеда.


в ОРМ передают не строки а классы
-----
А ОРМ является единственным обработчиком данных? Может прогеры делают еще хоть что-то помимо подготовки классов и модели для ОРМа?

Petro123,

Говно бд не работает с ОРМ.
-----
Эквивалентно:
Говно ОРМ не работает с бд.


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

Все это понятно, но не понятно почему не выполнить строгую типизацию поля первичного ключа и не парится с проблемами...

Аналогично непонятно - почему не использовать строго типизированное поле в объекте - куча бенефитов, начиная с того, что объект типа можно создавать фабрикой и он автоматом будет одного и тот же типа для всех 150-3000 вхождений...​


Мне не тяжело
-----
Мне - тоже... когда это делаю Я. Но как ты уже знаешь - это не всегда так...

Petro123,

и базу делаю руками.
-----
​И что же ты делаешь, когда базу тебе делать ниииизззяяя?


он не просит лишнего.
-----
Да ну? Ну и когда же он произведет типизированные поля?
Ведь так удобно - пишешь СКЛ - у тебя тип... пишешь БО - у тебя тип, причем еще и называется так же... пишешь ГУЙ - а у тебя - опять тип и опять так же называется...


если ты перепутал параметры...
-----
...Я хочу получить ошибку компиляции по несоответствию типов! Что-то в моем желании тебя смущает настолько, что не дает отклонится от требований ОРМов?


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

Petro123,

да. У поля Дата рождения тип поля дата.
-----
Не-а...
У поля Дата рождения тип поля ТДатаРождения​.
И, обязательно, защита от присвоения просто даты или ТДатаСмерти, но с допуском присвоения ТДатаРождения из ТСвидетельсво_о_Рождении.
Ну не хочу Я помнить куда какую дату можно поместить...

Petro123,

может это старость?)
-----
Возможно. Но скорее - древность...
Бо, по законам страны в которой Я родился Я уже должен быть пенсионером...
Это не мешает понимать проблемы и находить решения.
Но - да, уже медленнее...


нажал кнопу ... пишем что
-----
Вообще-то, в конторке где Я работал до этого, по нажатию кнопки строилось готовое к деплойменту приложение.
Единственное, что не делали - не встраивали в Студию. Но это Я в позапрошлом году исправил...


нужно их пробовать.
-----
Или разрабатывать.
Именно по этому мне не хватает типизированных полей - не справляются нынешние ОРМы...


Нужно не боятся работать.
-----
??? - Я не живу для того чтобы работать... Я, таки, зарабатываю, чтобы жить... и много мне не надо.

Petro123,

Но мы ведь о разработке.
-----
Именно. По-этому мне не понятна упертость в возможности сильно ограниченного ОРМа и нежелание поиметь что-то более удобное...

Petro123,

Как там было у Высоцкого: "Ты, Зин, на грубость нарываешься..."
За все время Я не видел ни одного дельного совета... с твоей стороны.
Но даже это не подвигнуло меня на выдачу каких либо оценок...
А об том с чем и сколько Я работал - Я уже писал.

Petro123,

Вы съехали с темы что у вас была кнопка
------

> Я считаю что это и есть программирование:
> - нажал кнопу :
???


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


что у вас была кнопка деплой
-----
Была - full rebuild & deploy, правда в командной строке...
Доработал, сделал обычный фоновый билд из Студии.

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

Petro123,

Приведите хотя бы 10 повторов.
-----
Ты бы ЕФ6 для начала научил работать с 8-м Ораклом... Ну или рассказал КАК, если умеешь...

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


Оправдайте потраченный ФОТ в 20 лимонов на разработку фреймворка.
-----
Всего около 120К и те уже давно отбиты...
Бо, не делали мы фреймворк - делали генератор приложений - там нет предопределенной функциональности и тут же его пользовали под заказчика.
А с генератором - все просто - обучить слабого прогера им пользоваться - без проблем, проще, чем учить кодить, билдить и деплоить из Студии. Потому как типичные ошибки неправильного использования данных при предельной типизации ловятся еще при компиляции.


Так Я не понял - будет пример с ОРМ по построению объекта с предельной типизации или будут только крики об том, что это нафиг не надо потому как не умеем?


Хочешь еще один "ненужный" вопросик?
Ты когда-нибудь строил ДЛЛку с модулями?
Ну типа - ДЛЛка всей базы одна (и махонькая, памяти кушает почти ноль), а каждая Модель из ЕФ компилируется в отдельный модуль (не ДЛЛку) и загружается как оверлей?
Я вот могу сказать, с уверенностью на 99,9%, что не делал...

Petro123,

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


Оракле могу посмотреть для 11 версии. Восьмерку выкинуть.
-----
​Для 11-го Я и сам может быть что-то смогу слепить. Меня интересует для того, с чем приходится работать...


вы сделали велосипед
-----
Т.е. вопрос об полезности предельно типизированной версии решен в пользу полезности и остается дождаться реального примера... от пользователя "высокоэффективной транспортной системы".


Про модули Я угадал?

Petro123,

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

Petro123,

Уволь.
-----
Ну вот - как только до конкретной инфраструктуры доходим - Уволь.​
Или, по простому - ОРМ есть Г. - с базой не работает.