МСУПарамонпропущено...

Покурю на досуге, пока не ясно )
Не кури, опять бредни Севы. OData в обсуждаемой теме никак не относится :)

SeVaOData содержит метаинформацию, а это в купе с динамическими объектами позволяет сделать одну универсальную реализацию и не плодить сущности на каждый чих.
Сдурел, что-ли? Ты бы еще рефлексию предложил в прикладном коде.

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

ViPRosМСУ,

не разговор не о датасетах и еще че то
ОРМ означет для меня что
1. Есть Объектная модель ОМ (т.е. вся работа по проблемной области сконцентрирована тут)
2. Есть Хранилище Х( в данном случае РСУБД)
3. Есть Прозрачный маппинг элементов ОМ в элементы Х

никаких других конструкцтий тут не должно быть
а с твоих слов выходит что в ЕФ ОМ сам по себе а работа идет с вспомогательными конструкциями какими то
концепция нарушена
ладно бы метод объекта автоматом маппировалась в ИДатаСервис (прозрачно), нет как я понял эти сервисы надо вручную создавать, а методы их вызывающие воще не относятся к ОМ
прально?


ViPRos, не ломай голову и не пытайся в этих детских гули-гули найти какой-то смысл. Детка делает первые шаги в ООП, но с полными подгузниками особо не разбежишься

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

Не кури, опять бредни Севы. OData в обсуждаемой теме никак не относится :)

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

Сдурел, что-ли? Ты бы еще рефлексию предложил в прикладном коде.

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


Попробуй с помощью с своего говнодата сервиса и прочего бреда изобразить то, что достаточно легко делается с OData.
Один контрол и несколько незамысловатых классов и больше нет проблемы с кучей DTO. OData Viewer Tool

Только тужься у себя в туалете, а не как обычно, на форуме

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


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

Сева, ты опущенец, которого все кому не лень опускают на форуме. Так было, так есть, так будет. Свыкнись со своей кармой, неуч.

Научись сначала угу-угу внятно бормотать, а когда подрастешь, может, и будут твое вяканье слушать.

ViPRosSeVa,

ну сама модель ОДата такая ж фигня как и ЕФ и т.д.
кроме Сущноси и Связи нет ничего
при это Сущность понимается как таблица в БД
нет понятия Схемы (именованный набор Связанных сущностей)

вот говрим Накладная и подазумрваем как минимум 2 Сущности - Шапка и Строки и связь между ними(в Випросе это макротип)
но в отдельности эти сущности нафиг никому не нужны кроме Мсушнего Идатасервис
Связь между Ш и С сильная
но тут же есть и слабыее связи - материал, ЕДИМ и т.д.
при задании схемы (макротипа) надо в мета указать сильные и слабые связи, направление зависимости и т.д.
а так из БД гоняете в БД
фигня все это

ViPRos, а не нужны никому эти жесткие связи и полное описание БД, тк смысл всех этих мультитков - уйти от зависимости структуры БД.Тк ООП и БД - две большие разницы. Помимо этого, нужны разные срезы данных(об этом говорилось в статье)
Вместо с танцев с бубнами для описания можно спокойно содать view за пять минут, запустить кодогенратор, а дальше если есть нормальный фреймворк, то больше делать ничего не нужно, все и так подхватится.
всесто БД - черный ящик, который предоставляет нужные интерфейсы. Помимо нее могут разные постащики данных(внешние сервисы, файлы, очереди сообщений, голубиная почта и тд).

SolYUtorLord BritishДавайте все же вернемся к EF, UOW, REPO и потроллим друг-друга на тему надо/не надо.
К сожалению, в тему заглянули только штатные тролли, поэтому развести дискуссию по существу будет напряжённо. :)

Могу лишь изложить поподробнее своё мнение. Сам прошёл путь Stored Procedure -> NHibernate -> Repository over Nhibernate -> NHibernate -> NoSQL (в процессе).

В общем, в процессе работы по принципу Repository over Nhibernate пришёл к пониманию, что мне просто не хватает возможностей, которые есть в NH, и я потихоньку привожу Repository к ISesson. В итоге просто выкинул ненужным мне слой. И чуть позже наткнулся на хорошие блоги по этой теме: раз , два , и (особенно для любителей SOLID'а) три . Сам я тоже любитель SOLID. Но кроме него, надо держать в голове и свой разум. Ибо видел совершенно "солидный", но абсолютно неподдерживаемый код.

И вдогонку. Вся эта суета вокруг слоёв вообще, и репозитория в частности задумывалась ради одной цели - сделать код более поддерживаемым за счёт повышения его понятности. И еще повторного использования кода. На самом деле, обычно гораздо проще для поддерживаемсяости использовать не горизонтальное деление - слои, а вертикальное - разделы. При этом используя как можно меньше псевдоабстракций. С повторным использованием, всё еще проще - 90% кода повторно не используется. На практике это выглядит так: прямо в коде MVC-контроллера берём сессию, строим запрос, бросаме результат во ViewModel. Просто, понятно, быстро, тестируемо. Profit.

Пока ты это проходил и искал, я это давно прошел и давно говорил тебе, что не нужно писать кипятком от твоего хибернейта.

SolYUtorПарамонТо есть весь BL в контроллере?
МСУВ NH ты в любом случае будешь строить свой репо
МСУЖесть, причем убийственная...



Такой запрос использован один раз, прямо в контроллере. DAL, Repository и тд. уже есть в виде сессии, дополнительные обёртки не нужны. Логика в классе Order, а не в контроллере.
Усложнять код, вводя новые слои, классы и т.д. не нужно. В реале есть пара Extension методов для постраничной выборки.

Если подобная логика в классе Order, то ты забрел не в ту степь. И здесь не соблюдается постоянно тобой цитируемый SOLID

Nhibernate LazyLoading в многослойном приложении

Вот одна из типичных проблем при использовании всех ORM. Начинают лепить городухи для ленивой загрузки, а они рассчитаны только под чистый CRUD