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