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,

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


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


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


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