вы бы определились, вам кажется, или это доставляет какие то проблемы.
я бы продолжил смотреть в сторону питона
Скорость развития - скорее минус, тк возникает большое колличество несовместимого или устаревшего кода.
Если какой-то компании надоест поддерживать яву, то найдется много других, которым она нужна так, что они вложатся в ее развитие
асп и шарп слишком поздно стали продвигаться на линуксах
Мне просто не упрощения в духе "сервер это модель", поскольку у приложения на клиенте тоже может быть своя модель, а сервер в этом случае лишь деталь реализации.
Я часто слышу фразы в духе "модель это база данных" или "модель это штука которая имеет доступ к базе данных".
извините, но с каких пор "база данных" это модель?
Ну мол с точки зрения JS клиента сервер это лишь способ синхронизации состояния с другими клиентами.
Или приложения, которые хранят все данные исключительно на клиенте и не имеют сервера как такового?
Вот здесь я немного Вас не понял - можете пояснить?Мысль в том, что пользователь репозитория не должен знать тонкостей получения данных из него. Он должен просто сказать репозиторию: "Дай мне юзера с вот таким ID", а репозиторий уже сам решает, какие сущности подергать, какие атрибуты с чем сравнить и т.п. Иначе логика доступа к данным размазывается по всему приложению.
достаточно сделать так: var unit = UnitOfWork.Repository().GetQuery(e => e.UserId == targetUserId)- вообще, такой маневр считается плохой затеей. Во-первых, получение юзера по ID может в разных местах быть нужно - плодим копипасту. Во-вторых, вылезает наружу логика доступа к данным, которую репозиторий по-хорошему должен инкапсулировать. Скажем, появится какой-нибудь флажок типа IsActive или IsDeleted, который тоже нужно учитывать - и придется шерстить весь проект, править вышеозначенные запросы.