в идеале ты делаешь вот так

class Door{ public int Id {get;set;} ... public DoorType DoorType {get; set;} } class DoorType { public int Id {get;set;} public int Name {get; set;} ... public List<Door> DoorList {get; set;} }

это поко классы для дб

так и есть

тогда в чём проблема получить сущность по айди

целую

изменить

и сохранить в дб?

есть же такая штука как Include

так она у меня вся и получена. Всё выводится. когда я меняю значение в combobox. нажима на сохранить. Смотрю значения, то получается что в TypeDoorID=1, TypeDoor.Id=2

dbContext.Door.Where(x => x.Id).Include(y => y.DoorType)

Получил сущность двери с её типом внутри

там все и так отлично грузится). Я про сохранение говорю)

зло*бучие ORM. Всё время писал хранимки в бд и рад был)))

там все и так отлично грузится). Я про сохранение говорю)

так ты потом пишешь в эту сущность доортайп

и пишешь Update и Save

с игрлоадом

но будет работать

Я понимаю что так могу. Но какого хуя она сама не сохраняетсЯ)

а потом может разберёшься что не так

хорошо, спасибо)

хорошо, спасибо)

У меня просто тоже траблы были с лейзи(

Но я не помню как решил

class Door{ public int Id {get;set;} ... public DoorType DoorType {get; set;} } class DoorType { public int Id {get;set;} public int Name {get; set;} ... public List<Door> DoorList {get; set;} }

а почему DoorType не virtual?

а ок, уже выше прочитал

хорошо, спасибо)

а можно посмотреть как контекст описан?

Вот вы даете

вроде ок всё, тогда я сути проблемы не понимаю

?

когда я пытаюсь поменять тип двери. вылетает ошибка

Суть проблемы - Entity Framework

просто выкинь его

логично. ты меняешь TypeDoor и не меняешь TypeDoorID

попробуй наоборот, поменять TypeDoorID и не трогать TypeDoor

тоже самое

Суть проблемы - Entity Framework

ЕФ норм

Вполне вполне

[Table("DoorTypes")] public class DoorType { [Key] public int Id { get; set; } public virtual ICollection<Door> Doors { get; set; } public DoorType() { Doors = new HashSet<Door>(); } //... } [Table("Doors")] public class Door { [Key] public int Id { get; set; } [ForeignKey("DoorType")] public int DoorTypeId { get; set; } public virtual DoorType DoorType { get; set; } //... }

тоже самое

а если сделать TypeDoor virtual?

Проще некуда

[ForeignKey("DoorType")] public int DoorTypeId { get; set; } public virtual DoorType DoorType { get; set; }

Во тут у него фейл

лол

[Key] public int Id { get; set; }

Можно ж не писать кей

и так виртуал. вернул как было изначально

у ефа это и так ке

й

[ForeignKey("DoorType")] public int DoorTypeId { get; set; } public virtual DoorType DoorType { get; set; }

ничто не мешает так сделать

Можно ж не писать кей

Я пишу эксплиситом, чтобы не тупить

Я пишу эксплиситом, чтобы не тупить

Справедливо

ничто не мешает так сделать

Я о Алексе

Вот что те сделать нужно

если ты ещё до сих пор не понял

у него тут уже описана связь

нет смысла добавлять атрибут вообще

не смотрел что тут

честно выглядит страшно

тут только предпоследняя строка интересует

Каша какая-то

честно выглядит страшно

Я про это и говорю, говно какое-то.

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

ERROR: S client not available

Я про это и говорю, говно какое-то.

Тут не ЛУЧШИЙ подход

А не ормка говно

А ты какие видел варианты, чтобы сравнивать?

А ты какие видел варианты, чтобы сравнивать?

Варианты кода или чего?

Или прокидывания фк?

Варианты работы с данными, кроме EF

Варианты работы с данными, кроме EF

НГибер, адо, даппер

Первое - совсем говно

Хехе, мне даже в проде ОРМ от Девекспресса юзать приходилось, лол. Вот там жесть

по поводу АДО - я бы его заюзал, даппер вроде тоже говном показался

Первое - совсем говно

Есть пара киллерфич

Первая - порт явы. А порты обычно говно

Потому юзается редко

АДО вполне норм

быстро

ЕФ надстройка над адо

Да, быстро и хорошо, жалко типизации строгой нет

обычно юзают еф для поко

+ даппер в тонких местах

то есть гибрид

по поводу АДО - я бы его заюзал, даппер вроде тоже говном показался

Даппер норм быстрый и мелкий

http://fsprojects.github.io/FSharp.Data.SqlClient/ - такое не думали юзать?

Вот это реально хорошая обертка над ADO

Не, оно конечно всё классно

Но вот ты прикинь, ты упираешься в стенку, нет коммунити, нет подсказок

И ты начинаешь писать костыли

Потом это надо поддерживать

Выигрышь небольшой перед АДО будет

А ебли много, оно того не стоит

EF - это много ебли, почти по дефолту

Вот ту ссылку, что я дал - это 10-20 строчек на F# и всё

ну то есть тупо весть DAL пишем на F#, наружу юзаем из C# как любой дотнет