FatherSql,

В топку хибер. Без вариантов и разговоров. Выкидываем и забываем.

EF хороший, годный ORM. Не идеальный, но вполне юзабельный, быстрый и гибкий.

НахлобучEF, каким бы "хорошим и годным" не был, так и остаётся сильно прикрученным к SQL Server'у и используя его с чем-то иным нужно быть готовым оказаться в "меньшинстве".

Херася, мужики-то не знали. В моём опыте использовался как минимум на 5-ке крупных проектов на Postgres, и несколько небольших, также Oracle, крупный портал и пару десятков АРМ-ов для предприятия, интернет-магазины с охватом РФ, на MySQL. И всё на EF.

Не надо гнать короче.

А хибер -- унылый тухляк, крайне неудачный форк с тупиковой ветвью развития, аминь.

Не хочешь себе проблем в будущем, никогда не ставь на хибер. Никогда, слышишь.

Нахлобуч,

И да, npgslq таки хорош. Но не единственный в своём роде.
Есть есть ещё Devart, тоже неплохой провайдер.

ViPRoshVostt,

покажи один из этих АРМов
ужас как хотся посмотреть хоть одну реальную прогу написанную аборигенами (токо не всякие там порталы-морталы,..)

А чем те порталы-морталы не угодили?

Хочишь, чтобы я засветил какие-нить скриншоты, на подобие тех, что ты неоднократно выкладывал? Или что? Доступ к коду дать? Тебе винрар или зип? )))) Сам-то понял чего просишь?

ViPRoshVostt,

покажи пару скринов и если возможно огрызок диаграммы БД и соответствующий огрызок "модели"

нет, я такое не практикую, и нигде ничего не свечу без согласия и согласования с работодателем. ни с прошлыми, ни с текущим. а своих продуктов я пока не выпускаю ))

ViPRosпортал-мортал - это твое чудо которое хочешь совать бесправной публике, они его не заказывали, потому и сожрут
а вот заказное ПО (типа твоих АРМ) пишется совсем по другому и выглядит совсем по другому

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

ViPRoshVostt,

неужели ты не можешь показать ничего? неужто ты все время работаешь на работодателя? хоть какие то вещи ты наверняка для себя прикидываешь как делать?
ну а если нет , то я мог бы дать допусти часть ТЗ которое вот только мне прислали, а ты б мин за 30 набросал бы модель и БД?

я обычно отталкиваюсь от бизнеса, реальные задачи мне интересны.

а модель можно было бы набросать, без проблем. если ТЗ вменяемое.

ViPRosхоть какие то вещи ты наверняка для себя прикидываешь как делать?

конечно, но опыт показывает, что лучшего решения не существует. есть приемлимое, плохое и худшее.

ViPRos,

ну чо, хде ТЗ )
а то я спать уже собираюсь

ViPRos,

вижу несколько решений.

через Query Object (аля Query Builder) запрашиваем и получаем накладные у слоя БЛ, где они отфильтровываются, в том числе по доступу, всё это возвращается как модель БЛ (не Entity/DTO), в том числе можно возвращать параметры прав для отображения/скрытия действий по строкам, ну и отдаём это добро в представление, что там MVC/MVVM.

действия реализуем как вызовы методов БЛ, классика.

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

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

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

ViPRos,

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

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

решений масса.

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

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

самый быстрый алгоритм, это проекции. и дофильтрация, самый оптимальный с точки зрения разработка/сопровождение/скорость выполнения.

опять же. для этого и существует слой БЛ, чтобы потребитель (прикладная часть ПО), могла просто сказать, дай мне накладные, или накладные со строками, или строки накладных, или документы накладных, где: <сконструированный фильтр>. и БЛ дофильтровывает запрос по правам текущего пользователя. наборы прав пользователей конечно желательно всегда кешировать, и не забывать про инвалидацию.

также ты можешь инкапсулировать некоторые вычисляемые значения (те же права) в свойства проекции, и фильтровать с потребителя прямо по ним. это уместно, если потребитель у тебя автомат, например, контроллер OData или REST-сервис.

ViPRosну прямо здесь делать нельзя - это просто разного рода напоминалки (типа такие то работы просрочены, тут затраты превысили бюджет, послезавтра надо позвонить Иванову,...) и эти напоминалки конструирует сам пользователь - типа "мои какие то задачи"

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