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

Как поступить?

Заталкивать одну и ту же логику и в конструктор с параметрами, и в конструктор без параметров? - Фигня получается, да и юзер может попытаться использовать конструктор без параметров без инициализатора объекта, что приведёт к сбою работы логики в нём.

авторЧто за инициализатор объекта?
http://msdn.microsoft.com/en-us/library/vstudio/bb384062.aspx

авторавторКак известно, LINQ не поддерживает конструкторы с параметрами.Что это за бред?
http://stackoverflow.com/questions/3571084/only-parameterless-constructors-and-initializers-are-supported-in-linq-to-entiti

авторЗа логику в конструкторе нужно скручивать руки и засовывать их догадайся куда.
Там логика, которая строит экземляр - свойства там заполняет и всё такое. В частности, в конструкторе выполняется запрос к БД через LINQ to Entities. Для этого нужны параметры.

AntonariyХотя может он и от линка скроется?
Ну да.

МСУuser7320пропущено...

http://msdn.microsoft.com/en-us/library/vstudio/bb384062.aspx
Причем тут LINQ?

user7320 http://stackoverflow.com/questions/3571084/only-parameterless-constructors-and-initializers-are-supported-in-linq-to-entiti
И в чем проблема?

user7320В частности, в конструкторе выполняется запрос к БД через LINQ to Entities. Для этого нужны параметры.
Расстреливать на месте.
А как надо?

МСУuser7320А как надо?
Честно признаться, я даже твою проблему не понял :) Напиши кодом, что у тебя не получается. Может, это трудности изложения...
У меня старая тема . Мне надо создать сложный объект, у которого есть поля-коллеции, у которых свои поля-коллекции и т. д. Все поля заполнить нужно из БД, причём выборки надо проводить по определённым параметрам. Вы там все упёрлись в репозиторий. И как тут поможет репозиторий или ещё какая штука, чтобы создать такой объект?

Я не знаю, почему EF не поддерживает конструкторы с параметрами, но если бы поддерживал, то у меня бы не было проблем.

МСУ
Смотри, как я придумал - и не надо в конструкторы передавать контекст или создавать по новому контексту в каждом конструкторе:



Если что, я раньше спрашивал, чтобы в конструктор типа GroupModel передать контекст БД или в нём самом создавать этот контект. Потому что коллецию Biogroups у типа GroupModel заполнял в конструкторе GroupModel. А теперь всё делаю один запросов в инициализаторах. Не то, чтобы я раньше об этом не знал... но как-то подзабыл. И получается, что тот вопрос отпал.

Ну, это же значительно лучше, чем у меня раньше было? Что вы об этом думаете?

И да, я пока не буду репозиторий использовать всё равно. Ведь раньше же как-то жили без репозиториев и ничего - спутники летали, корабли плавали.

Мне только интересно, во что такой запрос линка выльется в SQL. Наверное, там такая каша будет...

А как насчёт предложенного мной запроса выше ? Какие могут быть минусы при использовании таких... эмм... каскадов инициализаторов объектов в LINQ-выражениях?

skyANAА про обращение к БД в конктрукторе доменного объекта я промолчу.
Ну, вы как бы не замечайте этого. Я же сказал, что пока без репозитория.

skyANAuser7320, используется ToList(), то есть будет fetch из WeedGroups, и во время него будет выполняться запрос к Biogroups.
Может вылететь исключение, что нельзя открыть DataReader, т.к. уже есть один открытый.
А что значит "может вылететь"? Я вот запустил пару раз - и всё открылось и выполнилось. При каких условиях может, а при каких не может? Памяти ему не хватит, или количество DataReader'ов ограничего?



Я щас запустил этот код - странно, но почему-то он выдал "Only parameterless constructors and initializers are supported in LINQ to Entities". Это чего, и ReadOnlyCollection тоже нельзя применять, если она с параметров в конструкторе?

UPD. Вы меня уговорили. Вместо IReadOnlyCollection стал использовать IEnumerable. Но не потому, что так типа нужно, а потому, что в линке нельзя использовать параметризованные конструкторы (словил исключение - у ReadOnlyCollection конструктор всего один и обязательно с параметром). И да, убрал ToList в середине запроса. Но не потому, что там типа ДатаРидеров не хватит, а потому, что линк не понимает таких выражений (тоже словил исключение).

В результате получилось вот что. Ну, как теперь?

skyANAuser7320Это делается в репозитории. ЧЕСНА!!!Ага, так я и проверил. Использование this.Groups в этом не убеждает.
А в остальном... должно работать...
Я проверил - работает.


А у меня такой вопрос. Кто-нибудь смешивал в одном проекте ORM'ы EF от нескольких БД, при этом сами ORM'ы сгенерены EF разных версий? В частности, у меня в старом проекте надо было добавить функциональности, для этого требовалось подключение к дополнительной БД. Со старой БД соединялся с помощью ORM от EF версии то ли 1.х, то ли 4.0 - вобщем, когда он ещё не умел POCO делать. А с новой БД - с помощью POCO ORM. Ну, и в старом ORM вылетало исключение "Could not find the conceptual model type..." (ситуация типа такой ). В обоих случаях подходы Database First. Вынесение ОРМа новой БД в новый проект того же солюшена не помогло. Переделка старого ОРМа под POCO повлекла ошибки залогинивания, причём как при обращении к старой БД, так и к новой, что на одном сервере, что на другом (на моей машине копия по структуре продакшеновой БД стоит). Насколько я нарыл в Инете, это скорее связано с какими-то настройками то ли СУБД, то ли ОС с её правами доступа. Только штука в том, что если создать новый, пустой проект, и поместить туда два этих ОРМа (к новой и к старой БД), то всё работает и проблем с залогиниванием нет.

Я решил пока это так: вынес ОРМ к новой БД в отдельный солюшен, и подключился из старого солюшена к сборке солюшена с новым ОРМ.

Вобщем, я не прошу во всю эту писанину вникать, просто хочу узнать - кто-нибудь комбинировал ОРМы старых и новых версий EF (особенно с POCO и без) в одном проекте и были ли при этом какие-нибудь проблемы?

Где-то в степиuser7320,
все равно, репозитарий не буду делать (с)
Вы ещё скажите, что каждое ОРМ у вас в своём репозитории, а не все в одном.

user7320Где-то в степиuser7320,
все равно, репозитарий не буду делать (с)
Вы ещё скажите, что каждое ОРМ у вас в своём репозитории, а не все в одном.
А каждый репозиторий - отдельный солюшен.

Проблема-то всё равно должна остаться та же, что я описал.

skyANAuser7320пропущено...

Вы ещё скажите, что каждое ОРМ у вас в своём репозитории, а не все в одном.Когда реализован репозиторий, то изначально мы получает от него объекты доменной модели, и не нужно танцевать с бубном вокругuser7320Переделка старого ОРМа под POCO повлекла ошибки залогинивания, причём как при обращении к старой БД, так и к новой, что на одном сервере, что на другом (на моей машине копия по структуре продакшеновой БД стоит). Насколько я нарыл в Инете, это скорее связано с какими-то настройками то ли СУБД, то ли ОС с её правами доступа.и смешивать в одном проекте! EF разных версий.
Даже если вы будете делать репозиторий, вы же не откажетесь от EF? Так репозиторий у вас каждый в своей сборке по числу БД, или всё в одном проекте, да ещё и в том, что и основная программа? У меня проблема, что конфликтуют ORM от разных версий EF в одной и той же сборке.

skyANAuser7320пропущено...

Даже если вы будете делать репозиторий, вы же не откажетесь от EF? Так репозиторий у вас каждый в своей сборке по числу БД, или всё в одном проекте, да ещё и в том, что и основная программа?Да репозиторий каждый в своей сборке по числу поставщиков данных (это не обязательно БД).user7320У меня проблема, что конфликтуют ORM от разных версий EF в одной и той же сборке.Используй везде отдну версию EF, проведи рефакторинг. Так можно 100500 сторонних библиотек заюзать: в этом проекте используем такую версию, в этом другую, - что за зоопарк, блеать?
Или тебе предложить костыль? Загружай их в разные домены приложения. Но боюсь ты и вразных доменах на какую-нибудь херню напорешься.
А какой принцип, по которому вы разделяете на разные сборки куски приложения? У вас над каждым куском свой человек работает, поэтому вы потом все DLL линкуете, или как?

Вот, положим, есть шаблон MVVM в WPF. Вот эти вот M, VM и V тоже надо разделять? Скажем, модель в одну сборку, а модель представления и представление (т. к. они завязаны на одну технологию) - вдругую? Потом, скажем, слой общения с веб-службами, слой авторизации и аутентификации - тоже каждый в свою DLL? Плюс сборки - по одной на каждый репозиторий (т. е. на каждый поставщик данных)?

skyANAuser7320, я же написал, что репозиторий каждый в своей сборке по числу поставщиков данных (это не обязательно БД).
Что тут не понятно?
Непонятно, как делить программу на сборки окромя репозиториев.

skyANAuser7320пропущено...

Непонятно, как делить программу на сборки окромя репозиториев.Дак может её и не надо делить на сборки?

Приложения WPF с шаблоном проектирования модель-представление-модель представления
В начале статьи есть ссылка на исходники проекта. Посмотри как они организованы: разложены по папкам.
Начни с этого: разложи классы по файлам и папкам, а когда вдруг поймёшь, что отдельную папку стоит вынести в отдельный проект, то и вынесешь.

P.S.: в процессе изучения MVVM ты не наткнулся ни на один пример проекта?
Меня уже тошнит от той статьи. Я давно всё там перелопатил, включая пример проекта. Давно всё пихаю по папках (пространствам имён) и прочее. Я пробовал делать свой проект, где каждая часть (репозиторий, модели, модели представления с представлениями) разложены по своим солюшенам. Запускал три версии Студии и работал. Получилось хреново. Лучше, если уж на проекты делить, то всё в одном солюшене, ибо задолбало копмилить каждый раз три солюшена из-за того, что в солюшене моделей что-то поменялось (остальные-то части на модели ссылаются). Тут с EF получилось, что его ORM и его репозиторий лучше хранить в отдельном проекте потому, что старые версии EF были толи багованые, толи фичёванные , а не потому, что так "по архитектуре надо".

user7320 толи багованые, толи фичёванные
Кстати, у меня в обоих случаях "DB first", но ошибка такая же.

Может, папиффку? Ты у себя и своё, а я у себя и своё? ))

user7320skyANAА про обращение к БД в конктрукторе доменного объекта я промолчу.
Ну, вы как бы не замечайте этого. Я же сказал, что пока без репозитория.

skyANAuser7320, используется ToList(), то есть будет fetch из WeedGroups, и во время него будет выполняться запрос к Biogroups.
Может вылететь исключение, что нельзя открыть DataReader, т.к. уже есть один открытый.
А что значит "может вылететь"? Я вот запустил пару раз - и всё открылось и выполнилось. При каких условиях может, а при каких не может? Памяти ему не хватит, или количество DataReader'ов ограничего?



Я щас запустил этот код - странно, но почему-то он выдал "Only parameterless constructors and initializers are supported in LINQ to Entities". Это чего, и ReadOnlyCollection тоже нельзя применять, если она с параметров в конструкторе?

UPD. Вы меня уговорили. Вместо IReadOnlyCollection стал использовать IEnumerable. Но не потому, что так типа нужно, а потому, что в линке нельзя использовать параметризованные конструкторы (словил исключение - у ReadOnlyCollection конструктор всего один и обязательно с параметром). И да, убрал ToList в середине запроса. Но не потому, что там типа ДатаРидеров не хватит, а потому, что линк не понимает таких выражений (тоже словил исключение).

В результате получилось вот что. Ну, как теперь?




Есть ли смысл так делать, елси у меня свойство this.Groups типа IEnumerable? Тут ещё штука в том, что по этому свойству модели (ASP.NET MVC) надо в представлении не только пройтись форичем, но и знать число элементов этой коллеции, чтобы растянуть на это число ячейки в табличке. Использовать IEnumerable.Count() - лишний раз проходить по коллеции (я так понимаю, что этот метод именно проходит по ней, чтобы посчитать число всех элементов). Какой в таком случае лучше свойству this.Groups поставить тип? IList будет достаточно?

Где-то в степиuser7320,
авторя так понимаю, что этот метод именно проходит по ней, чтобы посчитать число всех элементов
Вы нехправильно понимаете, ну вы что - полный кретин, что документацию почитать не можете..
А как он узнаёт число элементов? Где об этом написано?

skyANAМда, и не стыдно такие вопросы задавать?

Enumerable.Count<TSource> Method (IEnumerable<TSource>)Remarks
If the type of source implements ICollection<T>, that implementation is used to obtain the count of elements. Otherwise, this method determines the count.
Я несколько раз ещё раньше прочёл эти строчки там и так и не понял, КАК ИМЕННО Count() получает число элементов. Беглый осмотр трёх результатов на StackOverflow привёл к ответам типа "только через итерацию, прямого свойства нет". Только углубившись, обнаружил пример, подобный вашему . Я так понимаю, это из исходников ("Рефлектором" посмотрели или что-то такое?)?

К сожалению, я больше реагировал на зелёные галочки там, забыв, что неграмотных или незнающих хватает и на StackOverflow, несмотря на их тыщи и десятки тыщь репутации.

Тогда касательно моего пример, если я в конце запроса вызываю ToList(), то возвращается список, который поддерживает ICollection и метод Count() может считать уже готовое свойство Count. Если же оставить результат как IQueryble, то Count() будет именно перебирать элементы. Правильно?


Стоит, однако, заметить, что это довольно неоднозначное поведение. Мне бы больше понравилось, если бы методы всегда перебирали элементы, а свойства - возвращали готовое значение. А так нужно всегда запоминать специальное поведение в специальных случаях, написанное где-то в глубине статьи мелким шрифтом.

Спасибо за наводки.

Где-то в степикак бы еще наводящий., в каких случаях выгодно орм выкидывать наружу чистый IEnumerable
При жадной загрузке?

user7320Где-то в степикак бы еще наводящий., в каких случаях выгодно орм выкидывать наружу чистый IEnumerable
http://stackoverflow.com/a/2876655/808128
Что-то я запутался... Ну вот. У метода Select есть два исполнения - для Queryable и для Enumerable вариантов. Судя по ссылке, они довольно сильно различаются по фактическому исполнению кода, а вот тут , например, предалагают в четвёртом примере в Remarks использовать лямбда-выражения вместо делегата Func. Подумаешь - делегат или лямбду! А то, что это будет либо в СУБД выполняться, либо у клиента на машине - внимания они не обращают?

Т. е. передал в параметр delegate(...){...} - получил исполнение в БД. Написал лямбду (что я всегда делаю, т. к. удобнее) - получил OutOfMemoryException?

user7320Т. е. передал в параметр delegate(...){...} - получил исполнение в БД. Написал лямбду (что я всегда делаю, т. к. удобнее) - получил OutOfMemoryException?
Т. е., наоборот - с лямбдой - на сервере, а с делегатом - на клиенте.

У меня сразу несколько вопросов возникло.


1.

авторIf the type of source implements ICollection<T>, that implementation is used to obtain the count of elements. Otherwise, this method determines the count.
А можете ещё пояснить эту фразу? Конкретно, какой вложенности "type of source" имеется ввиду? Например, я получаю результат запроса в виде IQuerayble, перевожу его в List через ToList(), потом отдаю это в свойство, которое показывает IEnumerable. Пользователь свойства считывает его и применяет метод Count(). В этом случае что имеется ввиду под "type of source": IEnumerable, List, IQuerayble или что-то ещё?


2.

Я так понимаю, что даже если в свойство попадает полнофункциональный List, то показывая его как IEnumerable, я обрезаю ему функциональность до банального перебора коллекции и только?


3.

Теперь учтём сразу 1 и 2. Пользователь моего свойства не знает, что служит источником для этого свойства. И если я показываю ему IEnumerable, то использовать расширение Enumerable.Count() он не имеет права, т. к. может загрузить как не знает, поддерживает ли источник этого свойства ICollection или нет. Так? Вот теперь тут всплывает наш старый спор - почему бы не заменить экспозицию свойства как IReadOnlyCollection на как IEnumerable, как предлагал skyANA. А потому что накладных расходов всё равно нет, если я в конце запроса вызываю ToList(), зато через IReadOnlyCollection я могу пользователю моего свойства явно сказать, что свойство можно не только перебирать, но и получить у него готовое число элементов Count, не боясь лишних переборов коллеции.

Т. е. если я сам пишу свойства и сам их использую - то да, можно IEnumerable и потом для него вызывать расширитель Count(). Но в общем случае надо всегда показывать через тип возврата, что можно делать, а что нельзя. Правильно?

Вот, например http://stackoverflow.com/questions/343466/does-dot-net-have-an-interface-like-ienumerable-with-a-count-property

skyANAuser7320Стоит, однако, заметить, что это довольно неоднозначное поведение. Мне бы больше понравилось, если бы методы всегда перебирали элементы, а свойства - возвращали готовое значение. А так нужно всегда запоминать специальное поведение в специальных случаях, написанное где-то в глубине статьи мелким шрифтом.Жалкая попытка оправдать свою глупость.
Я не пытаюсь оправдать свою глупость. То, что я глуп, видно и так - с этим глупо спорить. Я уже разобрался, как это работает. Меня теперь больше интересует мой последний длинный пост - я всё же там прав или нет, по-вашему?

Касательно этого моего поста. Нет, всё же, требование конструкторов без параметров в линке не даёт мне воспользоваться ReadOnlyCollection. Тогда остаётся узнать, что имеется ввиду под "the type of source ".

И ещё, есть способ узнать, при вызове Count() начинается итерация по коллеции или всего лишь считывается готовое свойство? Скажем, под дебагом залезть во внутрь Enumerable>Count() можно, и посмотреть, выполнилось ли там условие (если следовать примеру skyANA)




?

авторБлеать! Ты каким местом документацию читаешь?



Ну вот мы и видим, что IEnumerable<TSource> source не поддерживает Count(), а значит, расширитель будет использовать проход по коллекции.

Но если вы скажете, что тут задействована ковариация, и компилятор может определить, что под IEnumerable<TSource> source сидит какой-нибудь ICollection, и тогда он воспользуется его свойством Count без прохода по коллеции... Или вы так не скажите?

авторПод "the type of source" имеется ввиду конкретный тип параметра source!
Т. е. таки ковариация? - Любой тип, унаследованный от IEnumerable?

skyANAuser7320И ещё, есть способ ... под дебагом залезть во внутрь Enumerable>Count()? How to: Debug .NET Framework Source
Проверил - код сразу возвращает Count, а не вычисляет его. Значит, с ковариацией моя догадка была верна.