Комментарии 120
Продолжайте, интересно
Спасибо. Продолжу, конечно.
На самом деле — все примеры тут с живого сайта, над которым я сейчас работаю. Ещё пара доработок, и я с удовольствием выложу его на всеобщее обозрение.
На самом деле — все примеры тут с живого сайта, над которым я сейчас работаю. Ещё пара доработок, и я с удовольствием выложу его на всеобщее обозрение.
НЛО прилетело и опубликовало эту надпись здесь
Ладно, так и быть — не подумаю 8-)
По поводу всех ваших предложений — дествительно всё это актуально, сталкивался не раз с этими проблемами. Просто в моём тестовом проекте я себе этих проблем не создавал 8-) Думаю, можно будет сделать по отдельной статье на каждый из пунктов в вашем комментарии.
По поводу всех ваших предложений — дествительно всё это актуально, сталкивался не раз с этими проблемами. Просто в моём тестовом проекте я себе этих проблем не создавал 8-) Думаю, можно будет сделать по отдельной статье на каждый из пунктов в вашем комментарии.
В догонку к предыдущему комментатору, очень хотелось бы услышать о наследовании, которое есть в Entity Framework. Сам на него смотрел, но, если честно, не разобрался, как и на что оно влияет. На диаграмме возможность указать наследование есть, но оно не влияет на код.
Одно из препятствий, почему я не смог убедить менеджера проекта заюзать эту технологию — разработчик доменной модели посчитал, что без наследования эту штуку использовать накладно. А у меня как-то тяму не хватило с нахрапа взять эту вершину.
Одно из препятствий, почему я не смог убедить менеджера проекта заюзать эту технологию — разработчик доменной модели посчитал, что без наследования эту штуку использовать накладно. А у меня как-то тяму не хватило с нахрапа взять эту вершину.
Угу, помню каких трудов стоило самостоятельно разобраться с LINQ to SQL, с учетом того что всю жизнь писал на C++. Туториалы по ADO.NET EF для начинающих будут как раз кстати. Вобще, хороший пост, все доступным языком расписано.
А можете пожалуйста объяснить чем это лучше типизированных датасетов и насколько сложно обновлять модель в студии при ее изменении в базе?
Ну, сходу что вспомнил:
1) возможностью отложенной загрузки данных
в датасете нам надо заполнить все таблицы, чтобы воспользоваться отношениями между ними (или писать кучу лишнего и нетривиального кода для догрузки по необходимости)
в LINQ2SQL и EF догрузка может производиться в «ленивом» режиме без лишнего кода.
2) nullable-типы все-таки роднее языку, чем DBNull и дурацкие проверки IsBlaBlaBlaNull()
3) Вам когда-нибудь приходилось на лету заменять строку подключения или таймаут для команд типизированному датасету? Без рефлекшена затея обречена на провал.
В EF это можно сделать, вызвав альтернативный конструктор класса.
P.S. Можно менять модель непосредственно в студии, а модель уж сама внесет нужные изменения в базу. Хотя, верно и обратное.
1) возможностью отложенной загрузки данных
в датасете нам надо заполнить все таблицы, чтобы воспользоваться отношениями между ними (или писать кучу лишнего и нетривиального кода для догрузки по необходимости)
в LINQ2SQL и EF догрузка может производиться в «ленивом» режиме без лишнего кода.
2) nullable-типы все-таки роднее языку, чем DBNull и дурацкие проверки IsBlaBlaBlaNull()
3) Вам когда-нибудь приходилось на лету заменять строку подключения или таймаут для команд типизированному датасету? Без рефлекшена затея обречена на провал.
В EF это можно сделать, вызвав альтернативный конструктор класса.
P.S. Можно менять модель непосредственно в студии, а модель уж сама внесет нужные изменения в базу. Хотя, верно и обратное.
А Вы уверены, что EF поддерживает «ленивую загрузку»? Ссылку в студию. Удивите!
Насколько я знаю, EF в отличии от LINQ2SQL ленивую загрузку не поддерживает. А разработчики EF обосновывают отсутствие оной необходимостью соответствовать ООП. А именно, при маппинге иерархии классов на таблицы БД, теперь можно приводить сущности к любому из базовых классов, на который есть маппинг.
И прежде чем воспевать дифирамбы EF проанализируйте производительность DAL, реализованных на ADO.NET, LINQ2SQL, EF, Active Record(NHibernate). Оченьудивитесь.
И по поводу «менять модель непосредственно в студии». Вы сами-то пробовали так изголяться, или начитались «умных» книжек по EF?
Насколько я знаю, EF в отличии от LINQ2SQL ленивую загрузку не поддерживает. А разработчики EF обосновывают отсутствие оной необходимостью соответствовать ООП. А именно, при маппинге иерархии классов на таблицы БД, теперь можно приводить сущности к любому из базовых классов, на который есть маппинг.
И прежде чем воспевать дифирамбы EF проанализируйте производительность DAL, реализованных на ADO.NET, LINQ2SQL, EF, Active Record(NHibernate). Оченьудивитесь.
И по поводу «менять модель непосредственно в студии». Вы сами-то пробовали так изголяться, или начитались «умных» книжек по EF?
А можно подробнее про маппинг иерархии классов на таблицы БД? Поясните плиз на простом примере, что вы имеете в виду?
Ну, насколько я понял, у нас есть БД, из неё делается ANEF обёртка. А тут хотят наоборот — изменил что-то в ANEF получил в БД.
Хм. Совсем нет. Как мне кажется, 7y7 разговаривал про отсутствие ленивой загрузки в EF и обосновал ее тем, что к БД предъявляется жесткое требование соответствовать доменной модели. Я бы хотел уточнить момент про приведение мэппингующихся классов, потому что мне непонятно, что к чему приводится.
Суть в том, что приведение к классу наследнику не порождает подчиненных запросов, подтягивающих дополнительные данные. При инстанциации экземпляров сразу используется нужный тип и он заполняется всеми данными. По полиморфизму зачет.
А, понял.
Т.е. например, есть класс Car, есть наследник ColoredCar, в наследние дополнительное проперти висит — Color. В таблице у записей соотв. Car поле Color null. Мы загружаем все Car, и EF прочитает все Color, хотя вроде бы и не требовалось. Так?
Т.е. например, есть класс Car, есть наследник ColoredCar, в наследние дополнительное проперти висит — Color. В таблице у записей соотв. Car поле Color null. Мы загружаем все Car, и EF прочитает все Color, хотя вроде бы и не требовалось. Так?
Если работать с сущностью Car, то EF при загрузке из БД будет обращаться только к тем столбцам, на которые есть маппинг для Car.
А если мы загрузили ColoredCar, то эта сущность приводится к базовому классу Car без инициализации дополнительных запросов.
А NULL-ы висят в таблице при реализации схемы TPH. Т.к. таблица всего одна, и записи в нее происходят и для сущности Car, и для сущности ColoredCar.
А если мы загрузили ColoredCar, то эта сущность приводится к базовому классу Car без инициализации дополнительных запросов.
А NULL-ы висят в таблице при реализации схемы TPH. Т.к. таблица всего одна, и записи в нее происходят и для сущности Car, и для сущности ColoredCar.
Допустим, есть определенная иерархия классов. Entity Framework позволяет смаппить одну сущность на несколько таблиц. Для реализации наследования используют следующие схемы:
Table per Hierarchy. В этом случае вся иерархия помещается в одну таблицу, а поля сущностей маппятся на «свои» колонки таблицы, а в значениях остальных колонок содержится NULL.
Table per Type. При такой схеме БД, каждой сущности соответствует своя таблица. Плюсом является то, что БД нормализированная, но отсюда и минус, — при глубокой иерархии будет страдать производительность из-за джоинов.
Table per Concrete Type. В этот раз создаются таблицы для каждой ветки иерархии. И каждая таблица будет содержать поля промежуточных базовых сущностей.
Table per Hierarchy. В этом случае вся иерархия помещается в одну таблицу, а поля сущностей маппятся на «свои» колонки таблицы, а в значениях остальных колонок содержится NULL.
Table per Type. При такой схеме БД, каждой сущности соответствует своя таблица. Плюсом является то, что БД нормализированная, но отсюда и минус, — при глубокой иерархии будет страдать производительность из-за джоинов.
Table per Concrete Type. В этот раз создаются таблицы для каждой ветки иерархии. И каждая таблица будет содержать поля промежуточных базовых сущностей.
О, спасибо!
Не совсем понятно, чем иерархия отличается от конкретного типа? И там и там граф объектов ложится в одну таблицу, правильно? Во втором случае мы граф бьем на подграфы, так?
Не совсем понятно, чем иерархия отличается от конкретного типа? И там и там граф объектов ложится в одну таблицу, правильно? Во втором случае мы граф бьем на подграфы, так?
В первом случае будет всего одна таблица (при схеме TPH).
В случае TPC таблиц будет столько, сколько и сущностей, не имеющих наследников.
Пример: Есть базовый класс «Клиент», у него наследники «Юр. лицо» и «Физ. лицо». В первом случае будет только одна таблица (TPH), во втором случае (TPT) будет три таблица, так сущностей три. А в случае TPC будет две таблица, т.к. конкретных сущностей всего лишь две: «Юр. лицо» и «Физ. лицо».
В случае TPC таблиц будет столько, сколько и сущностей, не имеющих наследников.
Пример: Есть базовый класс «Клиент», у него наследники «Юр. лицо» и «Физ. лицо». В первом случае будет только одна таблица (TPH), во втором случае (TPT) будет три таблица, так сущностей три. А в случае TPC будет две таблица, т.к. конкретных сущностей всего лишь две: «Юр. лицо» и «Физ. лицо».
Поддерживает, правда немного иначе, чем LINQ2SQL. См. метод Load у навигационных свойств.
Дифирамбы EF я и не воспевал, просто привел пару плюсов перед типизированными датасетами. Это, скорее, дифирамбы конструктору вижуалстудии, чем самой технологии.
На одной маленькой базе пробовал. На сколько-нибудь серьезных вещах — не пробовал. «Умных» книжек не читал вообще.
Дифирамбы EF я и не воспевал, просто привел пару плюсов перед типизированными датасетами. Это, скорее, дифирамбы конструктору вижуалстудии, чем самой технологии.
На одной маленькой базе пробовал. На сколько-нибудь серьезных вещах — не пробовал. «Умных» книжек не читал вообще.
НЛО прилетело и опубликовало эту надпись здесь
Я просто думал, что на Хабре есть подробное описание ANEF, но не нашёл его. Придётся видать ещё и вводную статью делать 8-)
Ну, как раз-таки не все ORM работают именно с сущностями. EF — да, и это одна из положительных фич, мы можем работать с объектами как с сущностями предметной области, не привязываясь изначально к реляционной структуре.
Вот всегда нравились такие статьи! Во-первых актуально, во-вторых доступно. Автор, с нетерпением будем ждать продолжения.
Пара замечаний:
1) Утверждение "… это LINQ. Без него в ADO.NET никуда" неверно.
ADO.NET успешно существовал без LINQ несколько лет, LINQ — это лишь приятное удобство.
2) Зачем создавать лишние экземпляры класса? Это я, в частности, про строку 24. Разумеется, в рамках тестовой странички лишний Post — это мелочи, но все же… :)
Ну, а в остальном — хорошо, просто, доступно. Пишите еще.
1) Утверждение "… это LINQ. Без него в ADO.NET никуда" неверно.
ADO.NET успешно существовал без LINQ несколько лет, LINQ — это лишь приятное удобство.
2) Зачем создавать лишние экземпляры класса? Это я, в частности, про строку 24. Разумеется, в рамках тестовой странички лишний Post — это мелочи, но все же… :)
Ну, а в остальном — хорошо, просто, доступно. Пишите еще.
Ну и, возможно, есть смысл перенести в .NET?
автор, переносите в .NET
один вопрос: поделитесь кодом Helpers.TypographText :)
и еще замечание: не понял про какую «следующую версию Visual Studio 2008» идет речь, финальная версия EF доступна в 2008 студии с SP1. Скорее всего статья писалась давно, я не прав?
один вопрос: поделитесь кодом Helpers.TypographText :)
и еще замечание: не понял про какую «следующую версию Visual Studio 2008» идет речь, финальная версия EF доступна в 2008 студии с SP1. Скорее всего статья писалась давно, я не прав?
может автор имел ввиду что в 2010 она доступна из коробки без сп…
Хаха, вы только не смейтесь, ибо она пока больше заглушка, чем функция. Буду доделывать, и конечно опенсорсить.
public static String TypographText(String html)
{
//Regex rDefis = new Regex();
html = html.Replace(System.Environment.NewLine, "<br />");
html = html.Replace("- ", "— ");
html = html.Replace(" -", " —");
return html;
}
* This source code was highlighted with Source Code Highlighter.не забудьте еще anti-XSS воткнуть для надежности
Да, конечно. Там ещё непочатый край работы.
вообще, неплохо бы сделать универсальный .net-типограф и силами хабра отшлифовтаь его до зеркального блеска. предлагаю выложить ваш вариант, когда будет готов, и всем скопом обсудить
Да, я этим займусь, ибо пользоваться типографом того самого человека не хочется.
Какого «того самого»? А, с другой стороны, почему бы и нет? Есть какие объективные причины?
Ой, я только что на него глянул, и сам обмяк. Я думал, что там нет вэб сервиса, а оказалось есть. Тот самый — это Лебедёвский
Ну, на этом можно и закрывать тему типографа 8-)
Ну, на этом можно и закрывать тему типографа 8-)
А как мне кажется, лучше было бы не завязываться на одном типографе, а вполне себе нормально будет использовать любой из открытых в вебе, используя в методах типа «TypographText» обращение к этим сервисам.
То есть, я к тому, что зачем изобретать велосипед, когда они и так уже есть, причем достаточно хорошие.
То есть, я к тому, что зачем изобретать велосипед, когда они и так уже есть, причем достаточно хорошие.
не всегда удобно и имеет смысл обращаться к сервисам в интернет
это может быть затратно и в ряде случаев просто неприемлемо
это может быть затратно и в ряде случаев просто неприемлемо
вот вот 8-) Именно поэтому, мой типограф состоит из трёх строк 8-) Проблему эту решим, не критична щас 8-)
А вот тот факт, что у меня нет работы с юзерами — это неправильно.
А вот тот факт, что у меня нет работы с юзерами — это неправильно.
А про каких юзеров идет речь?
У меня же вэб проект, и как вы видите у меня есть таблица с пользователями. Но пока у меня нет никакой работы с пользователями. Нельзя даже зарегистрироваться на сайте.
А, ну так у вас же ASP.NET. Почему бы не использовать целый столп технологий, уже имеющийся у них? В частности, про подсистему Membership'а.
Признаться честно, я чуть не сблеванул, когда последний раз её юзал. Она не хотели ни в какую вязаться к существующей БД и насрала гавнокодом в БД. Ну, да в общем, я сам тогда был молод и вспыльчив. Щас буду разбираться, поохладив свой пыл 8-)
Да мы тоже писали свое, свое, но в итоге решили не поддерживать еще один сложный механизм в системах и стали использовать встроенный.
P.S. Насчет сблевануть — согласен конечно, очень некрасивый он этот механизм и чрезмерно усложненный, но работающий. Тут уже вопрос трудозатрат (т.е. хотите — пишите свое, но проще использовать что есть).
P.S. Насчет сблевануть — согласен конечно, очень некрасивый он этот механизм и чрезмерно усложненный, но работающий. Тут уже вопрос трудозатрат (т.е. хотите — пишите свое, но проще использовать что есть).
Эх… я с октября уже пытаюсь усесться как следует и портировать Jevix, да все никак не подвернется подходящий по размерам сегмент времени.
Пока что в своих проектах использовал утилиту, основанную на регулярках.
Конечно, можно прикрутить типограф «того самого», но он не позволяет резать теги и атрибуты.
Пока что в своих проектах использовал утилиту, основанную на регулярках.
Конечно, можно прикрутить типограф «того самого», но он не позволяет резать теги и атрибуты.
Эх, я помню, мы начали пробовать EF еще с первой беты (или чего-то там еще, в общем, что первое появилось в сети :).
Самое крутое реально то, что все эти технологии (ASP.NET MVC, EF, VS2008 Express) составляют очень мощный и при этом бесплатный базовый набор для веб-разработчика.
Самое крутое реально то, что все эти технологии (ASP.NET MVC, EF, VS2008 Express) составляют очень мощный и при этом бесплатный базовый набор для веб-разработчика.
Увы, увы, только в рамках парадигмы Майкрософтовского РАДа:) При более серьезной организации хранения данных или же увеличения сложности интеграции (когда данные нужно гонять между несколькими системами), разработанных дизайнером студии классов банально не хватает.
Ну дык! Работу по масштабированию, разработке инфраструктуры, оптимизации, виртуализации, кластеризации, интеграции и т. д. никто не отменял :) Я говорил только про базовый инструментарий.
Так фишка в том, что EF в таком случае уже не подходит. Имхо, сейчас EF пригоден для быстрого написания приложения, аля code-monkey, взял, натыкал, прибиндил, показал. Для суровых проектов лично я так и не смог разобраться, сможет ли EF удовлетворять предъявляемым требованиям. Скорее нет, чем да:)
Я просто за свою карьеру уже понанюхался этих самопальных фреймворков, хочется разобраться с чем-нить типа ANEF. Хотя, я и не думаю, что он универсален.
Скажем так, он «имеет свои ограничения» :) Как и любая технология. Но сам EF вполне себе уровня Enterprise. У нас наибольшие тяжбы EF вызвал в unit-тестировании. Там очень много нюансов и надо сначала как следует разобраться, прежде чем создавать mock-объекты сущностей.
М:) Можно подробнее? В чем была проблема? Почему интерфейсы не помогли?
Какие интерфейсы? :)
Насколько мне известно, ребята из технологического направления в итоге пользовались методом «Test-Specific Subclass» для сущностей Entity Framework'а.
Насколько мне известно, ребята из технологического направления в итоге пользовались методом «Test-Specific Subclass» для сущностей Entity Framework'а.
Ну смотря что значит для суровых проектов.
Меня вот, к примеру, очень даже радует тенденция MS движения в сторону того, что методом «пригоден для быстрого написания приложения, аля code-monkey, взял, натыкал, прибиндил» вполне можно решать задачи enterprise-уровня.
Меня вот, к примеру, очень даже радует тенденция MS движения в сторону того, что методом «пригоден для быстрого написания приложения, аля code-monkey, взял, натыкал, прибиндил» вполне можно решать задачи enterprise-уровня.
Согласен. Но, имхо, самая большая дыра, это отсутствие гибкости. Аналитики легко могут предъявить требования, которые банально могут не вписываться в архитектуру системы, вы не находите?
Тут вот прикол в том, что единственный аналитик — это я 8-) И бывает так (знаю по собственному опыту), что даже в очень крупной компании зачастую на аналитиков клали с высокой колокольни. Это очень печально, но это факт.
Во первых, вам повезло:)
Во вторых, вы не совсем правы. Аналитики, по большему счету, те, которые работают с заказчиком, документы пишут для заказчика. Если обычному программисту дать почитать то, что говорят аналитики, то у него как минимум зашевелятся волосы, ибо реализовать то, что пишут аналитики для заказчика нереально. Но однако, полным виженом системы могут обладать только те, кто общаются с заказчиком и вполне реально, что завтра вот та симпатичная девочка Таня подойдет к тебе и скажет «Илья, а нам нужно чтобы вот эта хренька работала вот так!» И ничего не останется сделать, как утерется:)
Во вторых, вы не совсем правы. Аналитики, по большему счету, те, которые работают с заказчиком, документы пишут для заказчика. Если обычному программисту дать почитать то, что говорят аналитики, то у него как минимум зашевелятся волосы, ибо реализовать то, что пишут аналитики для заказчика нереально. Но однако, полным виженом системы могут обладать только те, кто общаются с заказчиком и вполне реально, что завтра вот та симпатичная девочка Таня подойдет к тебе и скажет «Илья, а нам нужно чтобы вот эта хренька работала вот так!» И ничего не останется сделать, как утерется:)
Главное, чтобы делать надо было по-своему. А не так, как тебе сказал аналитик, или ни дай бог заказчик. А то есть некоторые — рассказывать нам, как работать с БД.
Стоп стоп стоп. Вы упускаете очень критический момент в разработке. Сделать своему не согласовав решение с аналитиком или с заказчиком — это значит огрести очень большой риск выкинуть то, что сделали. Вы не правы:) По-своему, не значит правильно и уж точно не значит так, как нужно заказчику (в конце концов, он же приемщик и он платит деньги)
Нет, если аналитик имеет голову на плечах — то его слово — закон. Хоть его можно обжаловать, но в общем — закон. А мне вот, к моему сожалению, не попадалось хороших аналитиков. Ну, просто проекты такие были. И на старых проектаз заказчик не только приносил требования к системе, но и ещё рассказывал нам, как правильно работать с БД на платформе, которой он не знал. Я именно про этот случай.
Ну так для этого есть ведь и менеджеры проектов :) Они и должны следить за целостностью требований и находить компромиссы (выделено, так как очень важный момент).
Вы никогда не работали с государственными заказчиками?:) Поверьте, с ними лучше не общаться с точки зрения компромиссов, я молчу про изменяющиеся в ходе разработки требования. Да в вообще говоря, вы про какие компромиссы?:) Легкие хотелки можно отфуболивать, но что касается написанного тз, то тут уж прости-подвинься, но изволь исполнить. Поэтому, имхо, хорошая архитектура, это такая архитектура, которая максимально гибкая. EF, к сожалению, такой гибкости не проявил, очень надеюсь, что пока не проявил и к 2010 студии ее дошлифуют.
Возможно, надо на реальных примерах смотреть тут уже. Согласен, что EF не идеален, но и не видел, чтобы ставил каких-либо прям совсем уж жестких барьеров. А так — будем надеяться на развитие технологии (я в этом, в принципе, уверен — MS позиционирует его как основной способ доступа к данным в базах для всех новых разработок на .NET и инвестирует достаточно, поэтому технология будет в порядке).
Задачка. Какое количество менеджеров проекта и аналитиков можно заметить в государственном университете?
Вариант два: Какое количество менеджеров проекта и аналитиков можно заметить в очень скупой компании? 8-))) Человеческий фактор.
Вариант два: Какое количество менеджеров проекта и аналитиков можно заметить в очень скупой компании? 8-))) Человеческий фактор.
Могут, согласен. Но, во-первых, всегда есть обратная связь с аналитиками и можно попросить их «придумать по-другому», либо, в крайнем случае, искать обходные пути.
Опять же, по опыту, EF — очень цельная технология, конечно не идеальная, но достаточно удобная и способствует очень быстрой разработке.
С точки зрения бизнеса, считаю, это тоже нормально — сделать выбор в сторону переписывания некоторых требований к системе, продолжая использовать технологию, которая экономит в итоге кучу времени в разработке и поддержке.
Опять же, по опыту, EF — очень цельная технология, конечно не идеальная, но достаточно удобная и способствует очень быстрой разработке.
С точки зрения бизнеса, считаю, это тоже нормально — сделать выбор в сторону переписывания некоторых требований к системе, продолжая использовать технологию, которая экономит в итоге кучу времени в разработке и поддержке.
Перечитал ваши коментарии, так и не понял чего вам не хватает в EF для масштабируемости, распределения, и других ентерпрайс задач.
Мне кажется то что он генерирует вполне можно допилить ручками до нужных требований. Вы можете привести то чего вам не удалось реализовать? Мне больше из образовательных целей интересно, чем поспорить с вами, только поэтому спришиваю. Ну и может тут коллективно решим :)
Мне кажется то что он генерирует вполне можно допилить ручками до нужных требований. Вы можете привести то чего вам не удалось реализовать? Мне больше из образовательных целей интересно, чем поспорить с вами, только поэтому спришиваю. Ну и может тут коллективно решим :)
Сейчас перечислю то, шо мне говорил мсье разработчик доменных моделей:
— Есть табличка Dictionary. Туда надо уложить граф объектов примерно четырех уровней вложенности (класс линейный словарь-класс иерархический словарь-класс словарь с ключем на другую таблицу-специфический класс словарь с ключем на другую таблицу плюс кучка энумов-пропертей в довесок). Я тогда мычал (мычал, потому что специализируюсь в клиентской части), что дескать, наследование есть, но надо в нем разобраться, и т.п. Сейчас те коменты, что выше, дают надежду на решение этой задачки.
— Задача срезок данных. Требуется загрузить не весь граф объектов целиком, а три связи. Например, ассоциации-ключ ассоциации-тип ключа (линейный словарь). Ну и сюда же до кучи (цитата) «вот возвращает у меня хранимка 5 табличек. Как я объясню EF'у, что у меня именно конкретные объекты переданы, а то и только ченжи».
— Вон народ выше на лэйзи лоад ругается. Надо мне, предположим, иерархический справочник (возьмем тот же ОКТМО со всеми муниципальными образованиями), пользователю давать открывать в дереве. Ну, я не спорю, можно извернутся и каким-то образом через линк подгружать объекты в дерево, но опять же, это надо пробовать, это надо настаивать что оно будет работать, убеждать и т.п.
Сами понимаете, как тяжело в наш нынешний век недоверия новым технологиям вводить инновационность:)
— Есть табличка Dictionary. Туда надо уложить граф объектов примерно четырех уровней вложенности (класс линейный словарь-класс иерархический словарь-класс словарь с ключем на другую таблицу-специфический класс словарь с ключем на другую таблицу плюс кучка энумов-пропертей в довесок). Я тогда мычал (мычал, потому что специализируюсь в клиентской части), что дескать, наследование есть, но надо в нем разобраться, и т.п. Сейчас те коменты, что выше, дают надежду на решение этой задачки.
— Задача срезок данных. Требуется загрузить не весь граф объектов целиком, а три связи. Например, ассоциации-ключ ассоциации-тип ключа (линейный словарь). Ну и сюда же до кучи (цитата) «вот возвращает у меня хранимка 5 табличек. Как я объясню EF'у, что у меня именно конкретные объекты переданы, а то и только ченжи».
— Вон народ выше на лэйзи лоад ругается. Надо мне, предположим, иерархический справочник (возьмем тот же ОКТМО со всеми муниципальными образованиями), пользователю давать открывать в дереве. Ну, я не спорю, можно извернутся и каким-то образом через линк подгружать объекты в дерево, но опять же, это надо пробовать, это надо настаивать что оно будет работать, убеждать и т.п.
Сами понимаете, как тяжело в наш нынешний век недоверия новым технологиям вводить инновационность:)
Спасибо за статью. Хотелось бы почитать о производительности EF в вашем проекте.
«позволяет создавать даталогику вашего проекта в пару кликов мыши» — дельфи стайл? :)
Спасибо, очень доходчиво.
Автор! Ты молодец! Немного критики.
Тематика интересна, но содержимое могло быть и лучше. На будущее, хотелось бы почитать вот о чем (о некоторых пунктах уже говорили):
— производительность EF vs NHibernate (ActiveRecord) vs true ADO.NET (ага, типизированные датасеты :)
— примеры хорошей архитектуры с участием EF (насколько я понимаю, вот прям так в конструкторе Поста создавать контекст БД как-то странно для боевых систем, хотя для семплов нормально)
— использование хранимок, составных ключей
— изменение модели «руками», перегенерация модели
— генерация схемы БД по модели (миф или реальность?)
Для начала хватит.
Тематика интересна, но содержимое могло быть и лучше. На будущее, хотелось бы почитать вот о чем (о некоторых пунктах уже говорили):
— производительность EF vs NHibernate (ActiveRecord) vs true ADO.NET (ага, типизированные датасеты :)
— примеры хорошей архитектуры с участием EF (насколько я понимаю, вот прям так в конструкторе Поста создавать контекст БД как-то странно для боевых систем, хотя для семплов нормально)
— использование хранимок, составных ключей
— изменение модели «руками», перегенерация модели
— генерация схемы БД по модели (миф или реальность?)
Для начала хватит.
Ах да: для того что бы рассказывать про EF, не отвлекаясь на ASP.NET, можно использовать консольное приложение.
Хотя Entity Data Source — прикольно, да :)
Хотя Entity Data Source — прикольно, да :)
Ну, на мой взгляд, смысл использовать ANEF в консоли отсутствует. Лучше сразу показывать на живых примерах. Ибо у новичков могут сразу возникнуть вопросы, типа: «зачем всё это вообще надо?». А так — сразу привёл всё к датасорцам, прибиндил, показал.
Тем более, я на ASP.NET написал приложений раз в 1000 больше, чем для WinForms и Консоли. Мне так удобнее 8-)
Тем более, я на ASP.NET написал приложений раз в 1000 больше, чем для WinForms и Консоли. Мне так удобнее 8-)
Хехе 8-) Ну, если бы я взялся сразу писать идеальную статью, то она бы была бесконечно длинной: Я бы её никогда не закончил, а вы никогда не прочитали бы 8-)
Эта статья — лишь маааленький пример. Конечно буду дополнять и расширять.
Эта статья — лишь маааленький пример. Конечно буду дополнять и расширять.
+1 к примеру о хорошей архитектуре:) Для двух таблиц выходит складно, но если их десять? Или, даже, так, если есть требование хранить в одной таблице граф объектов?
Насчет быстродействия можно почитать тут:
merle-amber.blogspot.com/2008/11/net-orm-2-sql.html
Насчет быстродействия можно почитать тут:
merle-amber.blogspot.com/2008/11/net-orm-2-sql.html
Единственный минус EF, который останавливает от продакшн использования это начисто отсутствующая система кеширования, даже стороннего решения найти пока не удалось, если так и дальше будет, то придется прикручивать свое.
Автору большое спасибо за отличное введение.
Ждем продолжения.
Ждем продолжения.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
У нас работала такая система, как вы описали. Вся логика имела достаточно простые методы, мы их дописывали, и всё было хорошо. Но потом пришла злая начальница, и сказала, что нам надо всё переделывать, и мы начали перешивать БД. Из 30-40 таблиц она пожирнела до 150, причём все они были жестоко переписаны. На каждую таблицу уходило по 4 маленьких класса, а в итоге, получалось что на выходе мы имели 450-600 классов, каждый из которых был реализован руками. Быстро у нас отпало желание поддерживать такую структуру. Тем более, с тестами всё хорошо, но мы работали по методам EP, на тесты не было времени. (Ну, это уж начальство такое, с ним ничего не поделаешь.) В итоге, там было бы лучше иметь одну самописную систему, в который все ошибки были бы видны, чем писать свою.
Пара замечаний по коду:
1. DataBaseCore.DbModel m = new DataBaseCore.DbModel();
Наверное стоит все же засунуть в using
2. p.User = (from usr in m.User where usr.Id == UserId select usr).First();
лучше заменить на
p.User = m.User.SingleorDefault(...);
1. DataBaseCore.DbModel m = new DataBaseCore.DbModel();
Наверное стоит все же засунуть в using
2. p.User = (from usr in m.User where usr.Id == UserId select usr).First();
лучше заменить на
p.User = m.User.SingleorDefault(...);
Спасибо, щас поправлю у себя в коде 8-)
Кстати, я думаю, что DataBaseCore.DbModel m вообще надо вынести в статики, пусть она одна висит постоянно рабочая.
Кстати, просто так, к слову и не в тему:) Один из бичей и багообразующих явлений в asp.net приложении (особенно для тех, кто пришел в asp.net из WinForms), это статики в asp.net. Хорошо работает, когда приложением занят один пользователь, если же пользователей несколько, то статики для них являются объектом синхронизации. Пользователи начинают перехватывать друг у друга команды, мешать использовать транзакции и т.п. Очень весело и пока догонишь, почему глючит, пройдет много времени.
Дада, у нас такое было. Приходится крутиться 8-)
Мы решили проблему тупым инстанциированием и полным отказом от статиков. У вас что-то поинтереснее?
Мы просто сделали так, что для всех однотипных действий был один статик класс. А если вдруг надо было сделать что-то что выбивало этот класс нафиг — можно было создать его инстанс и работать с ним. Например, как было с транзакциями.
Простите, а возможны применения технологий многопоточности в асп-нет приложении? Сам я занимаюсь толстыми клиентами, но возможно, скоро придется перпрофилироваться:)
Да. Это очень странно и неправильно, но можно 8-).
Именно многопоточность — это достаточно сложно. Но я видел реализации, которые запускали рендеринг объектов, в момент когда пользователю начинала отгружаться страница. И к моменту, когда надо было отдавать отренжереный объект, система уже была готова его отдать. Короче, всё было интересно, но вот я попой чуял, что что-то не очень хорошо.
А вообще — у нас была задача создания чата на основе ASP.NET + JS. Там надо было бороться с потоками.
Именно многопоточность — это достаточно сложно. Но я видел реализации, которые запускали рендеринг объектов, в момент когда пользователю начинала отгружаться страница. И к моменту, когда надо было отдавать отренжереный объект, система уже была готова его отдать. Короче, всё было интересно, но вот я попой чуял, что что-то не очень хорошо.
А вообще — у нас была задача создания чата на основе ASP.NET + JS. Там надо было бороться с потоками.
Почему это странно и неправильно???
Смотря какая задача. ASP.NET — это часть .NET, в котором вполне мощный инструментарий для многопоточности. И IIS работает с потоками, используя Thread Pools.
Смотря какая задача. ASP.NET — это часть .NET, в котором вполне мощный инструментарий для многопоточности. И IIS работает с потоками, используя Thread Pools.
Вот и хочу узнать, будет ли у меня, например, работать синхронизированный синглтон (это где в момент гета лочится объект синхронизации) в асп-нет приложении, если приложением будет пользоваться много пользователей?
Будет. У нас работает в виде окна чата. И сделать это можно разными способами.
Да, вполне возможно. Как, к примеру в СУБД может лочиться табличка на время вашего действия с базой. База — отдельное приложение. Также можете хостить свой Application-сервер в виде отдельного приложения (в том числе, в отдельном Application Pool на IIS).
Впрочем, в рядовом веб-приложении это врядли нужно, конечно. Лучше достигать производительности другими доступными методами, которых великое множество.
Не стоит. MS сама избавляется в новых разработках (таких как ASP.NET MVC) от статиков, имеющих кучу проблем с unit-тестированием. Всегда удобнее модель системы иметь в виде интерфейсов или базовых классов сущностей (ну, это по опыту).
НЛО прилетело и опубликовало эту надпись здесь
А можно тогда уточнить, статик-методы чего использовались?
А я говорил про то, что удобно, когда статик-методов и классов нет у модели приложения, так как при необходимости инстанциировать последнюю для проведения юнит-теста, наталкиваемся на приличный такой болт :) Ибо инстанциировать статик нельзя, задав для него определенные тестовые условия (там какие только мысли не были — вплоть до инстанциирования отдельного application-домена специально для того, чтобы в нем инстанциировались все статики и была уверенность, что никто и ничто эти статики не использует и не изменит).
А я говорил про то, что удобно, когда статик-методов и классов нет у модели приложения, так как при необходимости инстанциировать последнюю для проведения юнит-теста, наталкиваемся на приличный такой болт :) Ибо инстанциировать статик нельзя, задав для него определенные тестовые условия (там какие только мысли не были — вплоть до инстанциирования отдельного application-домена специально для того, чтобы в нем инстанциировались все статики и была уверенность, что никто и ничто эти статики не использует и не изменит).
Один коннешн на всех? ну ну %)
Уж сколько раз писали про эти грабли.
Уж сколько раз писали про эти грабли.
Моя ложка дегтя (сужу по проекту на существующей схеме БД):
Итак, минусы:
— Не умеет работать с датами. совсем.
— Хранимые процедуры и функции. Если возникла необходимось добро пожаловать в пользователи библиотеки EFExtensions, позволяющей выполнять голый sql.
— Неочевидные баги при смешивании в одном запросе entity sql с linq to sql или query builder methods.
— Отвратительный импорт. Во-первых, затирает все изменения, сделанные руками. Во-вторых, views из бд импортируются с проблемами — EF не может корректно указать у них первичный ключ, и в качестве оного берет все столбцы.
— Всякие мелочи, вроде остутствия правильного распознавания отношения многие ко многим в случае наличия в таблице-связке отдельного ключа (пример ID-GroupID-ProductID). Приходится заводить отдельную сущность.
— Отвратительный xml. При изменении сущности или отношения надо править его в нескольких местах.
— Сырость. Документации мало, community пока невелико.
Весомых плюсов (по сравнению с nHibernate) не нашел. Из положительного:
— Наличие отдельного gui редактора.
— Автоматическая генерация моделей. Стоит заметить, что в данном проекте эти модели не использовались за пределами DAL, чтобы была возможность перейти на другие способы получения данных из БД.
Итого, я рекомендую для проектов с существующей БД EF не использовать.
Итак, минусы:
— Не умеет работать с датами. совсем.
— Хранимые процедуры и функции. Если возникла необходимось добро пожаловать в пользователи библиотеки EFExtensions, позволяющей выполнять голый sql.
— Неочевидные баги при смешивании в одном запросе entity sql с linq to sql или query builder methods.
— Отвратительный импорт. Во-первых, затирает все изменения, сделанные руками. Во-вторых, views из бд импортируются с проблемами — EF не может корректно указать у них первичный ключ, и в качестве оного берет все столбцы.
— Всякие мелочи, вроде остутствия правильного распознавания отношения многие ко многим в случае наличия в таблице-связке отдельного ключа (пример ID-GroupID-ProductID). Приходится заводить отдельную сущность.
— Отвратительный xml. При изменении сущности или отношения надо править его в нескольких местах.
— Сырость. Документации мало, community пока невелико.
Весомых плюсов (по сравнению с nHibernate) не нашел. Из положительного:
— Наличие отдельного gui редактора.
— Автоматическая генерация моделей. Стоит заметить, что в данном проекте эти модели не использовались за пределами DAL, чтобы была возможность перейти на другие способы получения данных из БД.
Итого, я рекомендую для проектов с существующей БД EF не использовать.
Спасибо. Хорошая статья.
Сейчас как раз выбираю между Linq2Sql и EF для небольшого проекта.
Сейчас как раз выбираю между Linq2Sql и EF для небольшого проекта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ADO.NET Entity Framework близкое юзание