Разве не опасно иметь информацию о запросах в javascript, используя breezejs?

Просто начинайте играть с breeze.js из-за очевидной прибыли во время кодирования, т.е. управлять доступом к данным модели с сервера напрямую в Javascript (я новичок здесь, так очевидно, голый с!).

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

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

Спасибо!

ИЗМЕНИТЬ Очевидно, я не единственный, но я предполагаю, что существует разумный ответ - возможно, ограничение запрашиваемых данных с использованием методов DTO или чего-то еще? Другой вопрос размещен здесь

Ответ 1

Может оказаться опасным разоблачить полную бизнес-модель. Может быть опасно допускать безудержный запрос даже той части модели, которую вы хотите предоставить клиенту. Это верно, если вы предлагаете простой в использовании API или тот, который трудно запросить.

Вот почему наши команды осторожно относятся к тому, как мы строим наши сервисы.

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

Повторите: ваши методы обслуживания не должны возвращать IQueryable. Даже когда они возвращают IQueryable, вы можете легко написать метод службы, чтобы ограничить результаты запроса только теми сущностями, которые пользователь имеет право видеть.

К счастью, вы можете объединить два подхода в одной и той же службе или в службах совместной работы.

Бриз дает вам выбор. Вам решать эти выборы с умом. Выйдите и разработайте свои услуги в соответствии с вашими требованиями.

Ответ 2

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

Другими словами, это полезно для вас, если вы хотите, чтобы данные были общедоступными. Но только выставляйте объекты, которые вам нравятся, выставляя и позволяя кому-либо запрашивать; другой способ взглянуть на это заключается в том, что ваш API станет общедоступным API для вашего сайта (но вы не рекламируете и не говорите всем об этом).

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

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

Ответ 3

Как насчет того, когда вы обнаружите метаданные? Разве это не считается опасным. IMHO небезопасно раскрывать метаданные из DbContext. Я знаю, что вы можете создавать метаданные на клиенте, но нужно делать все как можно быстрее (если это безопасно).