Изменение типа поля на nullable у класса может привести к тому, что генераторы интерфейсов, использующие этот признак для подсвечивания обязательных полей и валидации данных на клиенте, перестанут считать поле обязательном, но эта проблема легко решается — модель теперь знает про default и наличие default == обязательное поле (default+nullable в базе игнорируем же, как будто нет дефолта). Это одна строка, не 300 конструкторов.

А может можно по аналогии с Nullable(Of T) сделать DBDefault(Of T). И DBDefaultNullable(Of T) для ценителей тонких извращений. При наличии во время инсерта null в DBDefault, исключать поле из вставки. И волки сыты и овцы целы.

LelouchAntonariy,

То есть ошибки не будет если я сделаю поля не nullable как того требует бизнесс логика?)Ошибка будет, как того требует бизнес-логика, и с теми же последствиями, но немного в другом месте программного кода.
Иди лекарств прими и научись читать и понимать прочитанное.

LelouchИ так вы ССЗБ, сначала создали базу, не думая о применении EF, а теперь со всей этой фигней пытаетесь взлететь )Когда создавалась база, дотнета еще в природе не было.

LelouchХотите галку - вам вооот сюда: http://entityframework.codeplex.com/ :)Слишком дохрена сорцов, мне никто не оплатит потраченное на их раскуривание время.

МСУAntonariyпропущено...
Поправил.
Ничего нового.
Поясни. Я говорю о EF в частности.В сферическом — в смысле оторванном от конкретной базы, конкретного проекта, конкретной внутренней архитектуры. Документированной.

Поэтому
МСУP.S. Все твои феерические выкрутасы с null и default(T) - бред сивой кобылы. Похоже на игру "угадай-ка", не более того.не убедительно. До сих пор я не увидел ни одного вменяемого аргумента, почему это бред или безобразие, не увидел указаний на проколы в логике выкрутасов. Видел попытки ее переврать, это да. Я привел пример сценария, с которым работаю сам, и показал, как это на нем отразятся изменения. Поэтому без указаний на его слабые места или примеров на других сценариях — до свидания.

Смена не nullable на nullable(t) отражается на клиентской логике, умеющей пользоваться этим атрибутом , но не на модели. На не умеющей не отражается вообще. Для меня ерунда, но всякие истерички уже, не вдаваясь в детали, приготовились падать в обморок, поэтому забудем этот вариант ради их здоровья.

Смена не nullable на default(t) совсем другое дело. Поведение default(t) строго определено:
1) можно присваивать null полю объекта,
2) исключается null при инсерте,
3) генерируется null exeption при апдейте

Это не замена одной обработанной ситуации другой обработанной (if(nullable){}else{}, это единственное место и есть страшная угадайка) с теоретическим (практически такая ситуация может возникнуть лишь целенаправленно, но не случайно) нарушением логики, а введение новой, имеющей известное поведение, и обработку которой нужно обдуманно ввести. Но даже из такой шляпы может выскочить пасхальный кролик: обработчик, написанный в виде if nullable else даже не надо менять! Мы не рассматриваем ситуацию, когда поле в бд имеет и null и default — в этом случае просто nullable, как сейчас. Следовательно, default(t) на клиенте ведeт себя точно так же как не nullable(t), то есть else, и ничего по этому поводу делать вообще не надо. На сервере же нельзя будет словить null exception при десериализации, но оно будет сгенерено фреймворком, если тот заметит попытку выполнить операцию апдейта базы default-полем, имеющим null. Требования модели выполняются целиком и полностью, нет ни одной угадайки.

Итого: смена не nullable на default(t) в идеальной ситуации не отражается на коде разработчика ни на клиенте ни на сервере, в не идеальной требует мизерной доработки клиентской части, что не сопоставимо с тремястами конструкторами. В остальном разница проявляется лишь в том, в каком месте будет null exeption: в коде разработчика при десериализации или в коде фреймворка при попытке апдейта бд.

МСУAntonariy, если уж говорить о дефолтах, то самый правильный вариант решения задачи был бы в виде связки атрибута с дефолтным значением и INotifyPropertyChanged, который мог бы ответить на вопрос, было ли изменено свойство. Если оно не было изменено, то EF транслятор брал бы значение из атрибута. Но такая логика не реализована в EF.Да не нужно EF ничего знать о значении дефолта, и ни с чем связывать и брать его ниоткуда не надо. Все это лишнее. Надо лишь знать о его наличии и давать базе самой его прописывать в свою же таблицу.

МСУЗавязка на null и default<T> через конструктор - абсолютный бред,Это твой бред и у него есть причина:МСУAntonariy, мне лень читать твою генерацию потока сознания.

Я по отдельности рассмотрел не nullable -> nullable(t) и не nullable -> default<T>, и упомянул, что сейчас из за отсутствия этих возможностей дописываю конструкторы с дефолтами. Никакой связи. Кони с людьми перемешались в твоей голове, а не моих словах.

ViPRosAntonariyЯ по отдельности рассмотрел не nullable -> nullable(t) и не nullable -> default<T>, и упомянул, что сейчас из за отсутствия этих возможностей дописываю конструкторы с дефолтами. Никакой связи. Кони с людьми перемешались в твоей голове, а не моих словах.
ЕФ крут !Да! Но может быть еще круче :)

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

Алексей Кзы: Ни в коем случае нельзя делать это в конструкторе, по понятным причинам...Так как я только начал изучение ORM, мне это не понятно. Можете просветить?

ViPRosпрально это надо в другом местеЭто что за место? Ничего знакомого на скриншоте.

ViPRosAntonariyпропущено...
Это что за место? Ничего знакомого на скриншоте.
место, где описывается предметная область - модель"Ну экран, ну кнопки, а говорить-то куда?" (б)
Где физически хранятся значения дефолтов? Поддерживаются ли формулы?

Алексей ККонструктор вызывается всегда. В том числе и в случае создания объекта в результате выполнения LINQ-запроса.Да, в этом случае последствия далеко идут. Побежал переписывать.