OData Restier - зачем это подходит? Стоит ли использовать его в производстве?

Question

Мне нужно мнение человека, который использовал/использовал «Restier» в производстве.

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

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

Мое мнение - «Restier» предназначен для очень простых проектов RESTful, таких как адресная книга, список дел и т. Д. Если вы разрабатываете большое коммерческое приложение, которое управляет сложной схемой данных и управляет денежными транзакциями, вам следует избегать использования «Restier» в проекте.

Любые мысли оценили.

Answer 1

REST - это архитектурный стиль для веб-сервисов. OData - это стандарт, который описывает надежную независимую реализацию REST. RESTier - это библиотека, которая реализует OData V4.

Сложность вашего домена должна быть в вашем домене и уровне приложения. Вы можете использовать RESTier, чтобы выставлять свою функциональность домена как WebService так, как вам нравится. Вы можете раскрывать свои сущности только для операций чтения и раскрывать свои варианты использования (Application Layer) как действия и функции OData, которые могут быть использованы любым клиентом (iOS, Android, веб-клиент, такой как Asp.Net Mvc, Wpf, любой JavaScript Frontend и т. Д.) Если у вас есть сложный домен, я бы предложил вам изучить Domain Driven Design.

Теперь вопросы ...

Что касается безопасности, вы можете реализовать все благость Asp.Net в Restier.

Что касается формирования данных, вы никогда не подвергаете объекты домена непосредственно через веб-службу. Я бы предложил реализовать фабрики, которые конвертируются туда и обратно между Клиентом (доменом, который представляет бизнес-логику) и CustomerDto (простой объект передачи данных). С помощью этого вы можете сформировать свои данные, чтобы их можно было разоблачить, как вам нужно.

Наличие бизнес-логики в интерфейсе (UI Layer), как вы упомянули, считается анти-шаблоном (анти-шаблон UI), если у вас большая сложность в домене. (Для простых приложений CRUD все в порядке). Restier не толкает вас в этом направлении. Речь идет о том, как вы строите свое решение.

Надеюсь, это вам поможет.