Оффтопик.
Ну, каждый пользуется чем-то своим, может более любимым, чем что-то конкурирующее. Нет ничего безликого. И есть преимущества и недостатки. Это мотивирует на то, чтобы рассказывать и дискутировать.
В остальном, есть правила.
Вы прекрасно понимаете, о чём я говорю, EF-технология ORM «по-умолчанию». Всем же ясно, что это и кем сделано. Разумеется, чисто технически вам надо поставить соответствующий пакет. Пойду так и исправлю статью.
Диаграммы классов решают ваши проблемы.
Нет, в том виде, как реализовано в студии, не решают, я ответил товарищу выше, почему.
А что за однотипный код вы пишете сотнями раз, и откуда у вас возьмутся корректные картинки для его генерации?
Я считаю, что код по описанию в классах сущностей, их свойств и т.п. является однотипным, разве нет? Это сущности и их отношения и ничего более.
Надо вручную инициализировать первичные ключи.
Нет, не надо. Просто проставьте их как создаваемые на стороне БД.
А, так вам внезапно надо знать, какой ключ будет у объекта до его сохранения? Тогда инициализируйте его сами, он же вам нужен. Да, еще у объектов есть конструкторы.
Представьте себе, да, надо знать заранее. Есть масса задач, где это надо. Например, есть устройство самообслуживания, не имеющее постоянного доступа к БД. И ключи сущностей знать надо заранее, чтобы хотя бы логи потом разбирать, чтобы они были одинаковые, как в БД, так и на устройстве.
Вы предлагаете мне написать в каждый конструктор означивание первичного ключа. Или в каждом месте, где это потребуется. Сейчас у меня другой способ: в ORM, которую я юзаю, есть понятия «тип первичного ключа» и «генератор первичного ключа». И делаю я это декларативно, один единственный раз. Если мне нужно какой-то особенный закон генерации ключей (да, есть задачи, где недостаточно обычного GUID или целого), я пишу свой генератор и также один раз декларативно подключаю.
Да, это продуктивно. Особенно это продуктивно в сочетании с соответствующими инструментами навроде мапперов и контролов.
Представляете, я не пишу никаких мапперов! Я просто декларативно определяю проекцию как множество собственных полей и полей связанных сущностей. И дальше её использую. Более того, такие множества специально именуются, так, что я всякий раз, когда мне надо, просто беру проекцию по имени, и всё. «Дай сущности в такой-то проекции». Всё. Более того, проекция задаётся прямо на диаграмме классов, визуально, в диалоговом режиме. Поверьте, делается это очень, очень быстро.
Да, так удобно, потому что это операции от совершенно разных действий. Add — это обычное добавление из CRUD, а Attach — это операция из detached entity management. В норме вы используете либо всегда одно, либо всегда другое, но не оба сразу. Да, и именно поэтому после Attach нужно проставлять статусы.
Представляете, когда я сейчас пишу прикладной код, я не думаю о CRUD, состояниях объектов, и какие там действия предпримет ORM (хотя могу). ORM делает это сам, как и резолвит зависимости между связанными сущностями. Ведь ежу понятно, что если я сделал new, будет только insert в БД, а если я что-то прочитал, то create всяко не будет.
Нет, понятно, что EF — не панацея. Но это удобный ORM с LINQ-интерфейсом, активно растущий и потихоньку избавляющийся от своих болячек. Основная-то масса описанных проблем все равно проистекает из самой концепции ORM (aka OR impedance mismatch), а не из реализации в EF.
Позащищаю я ORM. Как обычно, конечно же нет никаких «серебряных пуль» и всякая задача прежде всего инженерная задача. А всякий инструмент обладает своими ограничениями. И инструмент подбирается внимательно и тщательно. Сама концепция ORM — очень хороша, т.к. повышает производительность труда. И это хорошо. Просто, похоже EF — не очень хорошая реализация, и это удивительно для меня, человека, который просто столкнулся с ней сильно после всех остальных (так уж случилось) и глянул как на что-то новое. ORM должен позволять настроить всё очень тонко и очень детально. Ну и конечно, там где ORM явно плох, не надо его использовать. Например, писать отчёты. Ну, вы поняли…
Если будет возможность, напишу отдельную статейку, как планировал, по поводу того, что мне хочется от ORM.
Ответ очевиден. Потому что это именно «визуализация», а никак не «проектирование». Например, никак не учитывается реляционная специфика. Для примера, я хочу прямо с диаграммы указать название таблицы в базе для хранения сущностей определённого класса. Или указать имя поля. Сейчас я могу это легко делать в том, чем я сейчас пользуюсь. CodeFirst+«визуализация», не могу, мне придётся пойти в код и сделать это «вручную». CodeFirst ведь. :-)
Опять же, нарисовал, нажал кнопку, — получил классы и БД. Если нужно получить изменения: нажал кнопку, получил DDL для изменения структуры базы и опять же код классов соответственно изменился. А в код лезть в каких-то очень исключительных случаях.
Статья о совершенно конкретных проблемах. В руки попадают проекты, у которых, например, code-first и х.з. как настроено отображение в базу. И ни одной картинки. И сотни классов. Разобраться очень трудно.
Признаю вашу правоту в том, что «не очень-то и хотелось», т.к. в новые проекты я EF не беру, есть другой инструмент, который я считаю более удобным как по концепциям, так и по реализации. Там и диаграммы классов есть и много ещё чего интересного, напишу, если дадут.
С Include негодование очень даже понятное. Когда я вижу что-то навроде:
я думаю, бедная-бедная СУБД, несчастный сервер приложений.
По факту, это значит, что программист, который это написал, сообразил, что ленивая загрузка — это плохо (запросов много), но писать проекции заленился, т.к. это муторно. И дальше надо писать маппилки будет, тоже лень. Ясно, что это проблема программиста, однако, если бы был предложен инструмент, позволяющий это быстро сделать, не было бы ему так лениво написать по-человечески. Ну и потом, это же всё отнимает время.
Оффтопик.
Ну, каждый пользуется чем-то своим, может более любимым, чем что-то конкурирующее. Нет ничего безликого. И есть преимущества и недостатки. Это мотивирует на то, чтобы рассказывать и дискутировать.
В остальном, есть правила.
Вы прекрасно понимаете, о чём я говорю, EF-технология ORM «по-умолчанию». Всем же ясно, что это и кем сделано. Разумеется, чисто технически вам надо поставить соответствующий пакет. Пойду так и исправлю статью.
Нет, в том виде, как реализовано в студии, не решают, я ответил товарищу выше, почему.
Я считаю, что код по описанию в классах сущностей, их свойств и т.п. является однотипным, разве нет? Это сущности и их отношения и ничего более.
Представьте себе, да, надо знать заранее. Есть масса задач, где это надо. Например, есть устройство самообслуживания, не имеющее постоянного доступа к БД. И ключи сущностей знать надо заранее, чтобы хотя бы логи потом разбирать, чтобы они были одинаковые, как в БД, так и на устройстве.
Вы предлагаете мне написать в каждый конструктор означивание первичного ключа. Или в каждом месте, где это потребуется. Сейчас у меня другой способ: в ORM, которую я юзаю, есть понятия «тип первичного ключа» и «генератор первичного ключа». И делаю я это декларативно, один единственный раз. Если мне нужно какой-то особенный закон генерации ключей (да, есть задачи, где недостаточно обычного GUID или целого), я пишу свой генератор и также один раз декларативно подключаю.
Представляете, я не пишу никаких мапперов! Я просто декларативно определяю проекцию как множество собственных полей и полей связанных сущностей. И дальше её использую. Более того, такие множества специально именуются, так, что я всякий раз, когда мне надо, просто беру проекцию по имени, и всё. «Дай сущности в такой-то проекции». Всё. Более того, проекция задаётся прямо на диаграмме классов, визуально, в диалоговом режиме. Поверьте, делается это очень, очень быстро.
Представляете, когда я сейчас пишу прикладной код, я не думаю о CRUD, состояниях объектов, и какие там действия предпримет ORM (хотя могу). ORM делает это сам, как и резолвит зависимости между связанными сущностями. Ведь ежу понятно, что если я сделал new, будет только insert в БД, а если я что-то прочитал, то create всяко не будет.
Позащищаю я ORM. Как обычно, конечно же нет никаких «серебряных пуль» и всякая задача прежде всего инженерная задача. А всякий инструмент обладает своими ограничениями. И инструмент подбирается внимательно и тщательно. Сама концепция ORM — очень хороша, т.к. повышает производительность труда. И это хорошо. Просто, похоже EF — не очень хорошая реализация, и это удивительно для меня, человека, который просто столкнулся с ней сильно после всех остальных (так уж случилось) и глянул как на что-то новое. ORM должен позволять настроить всё очень тонко и очень детально. Ну и конечно, там где ORM явно плох, не надо его использовать. Например, писать отчёты. Ну, вы поняли…
Если будет возможность, напишу отдельную статейку, как планировал, по поводу того, что мне хочется от ORM.
Опять же, нарисовал, нажал кнопку, — получил классы и БД. Если нужно получить изменения: нажал кнопку, получил DDL для изменения структуры базы и опять же код классов соответственно изменился. А в код лезть в каких-то очень исключительных случаях.
Признаю вашу правоту в том, что «не очень-то и хотелось», т.к. в новые проекты я EF не беру, есть другой инструмент, который я считаю более удобным как по концепциям, так и по реализации. Там и диаграммы классов есть и много ещё чего интересного, напишу, если дадут.
С Include негодование очень даже понятное. Когда я вижу что-то навроде:
я думаю, бедная-бедная СУБД, несчастный сервер приложений.
По факту, это значит, что программист, который это написал, сообразил, что ленивая загрузка — это плохо (запросов много), но писать проекции заленился, т.к. это муторно. И дальше надо писать маппилки будет, тоже лень. Ясно, что это проблема программиста, однако, если бы был предложен инструмент, позволяющий это быстро сделать, не было бы ему так лениво написать по-человечески. Ну и потом, это же всё отнимает время.