Закон Деметры против REST

Question

Закон Деметры (действительно должно быть предложение Деметры) говорит, что вы не должны «добираться» до объекта, чтобы добраться до своих дочерних объектов. Если вы, как клиент, должны выполнить какую-то нетривиальную операцию, большую часть времени, когда модель домена, с которой вы работаете, должна поддерживать эту операцию.

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

Итак, как вы балансируете REST и Demeter? Мне кажется, что они не конфликтуют, потому что REST - это все о сверхсовременной связи с тем, что провайдер не имеет смысла пытаться предвидеть все потребности клиентов, тогда как Demeter предполагает, что логика может мигрировать к ее самый естественный место через рефакторинг.

Однако вы можете утверждать, что REST - это всего лишь промежуточный зазор, пока вы не поймете своих клиентов лучше. Является ли REST просто взломом? Неужели Demeter нереалистичен в любом сценарии сервера/клиента?

Answer 1

• Является ли Demeter нереалистичным в любом сценарии сервера/клиента?

Думаю, вы ответили на свой вопрос здесь. Как REST таким образом отличается от SOAP или XML-RPC в этом отношении?

Точка REST не является предоставление супер-слабосвязанности, но следующее:

• Предоставить идентификатор, который точно описывает ресурс запрашивается.
• Предоставление услуг, которые ведут себя, как и ожидалось GET запросов идемпотентны, PUT обновляет запись, POST создает, DELETE удаляет
• Минимизации состояния хранятся на сервере
• Сорвите ненужную сложность

Есть случаи, когда REST - не лучший ответ, но REST работает замечательно хорошо в общем.

Answer 2

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

Answer 3

Я думаю, что они действительно ортогональны. REST описывает коллекцию ресурсов, адресуемых URI, с набором канонических методов: GET, POST и т. Д. Если REST-процедура возвращает URI, это не «достигает», это идентифицирует другой объект с тем же именем метода.

Answer 4

Ссылка, предоставленная представлением, отображаемым интерфейсом RESTful, может быть полностью непрозрачной без нарушения каких-либо ограничений REST. Поэтому я бы предложил, чтобы REST полностью соответствовал Закону Деметры. Нет требования, чтобы ссылка отображала структуру URL-адреса в URL-адресе.

например. в объектно-ориентированном сценарии вы можете заменить вызов a.b.c на a.Ьс

В RESTful представлении можно создать следующее:

<a> 
    <link href="bc"/> 
</a> 

а не делать

GET a 

    <a> 
     <link href="b"/> 
    </a> 

GET b 

    <b> 
     <link href="c"/> 
    </b> 

GET c 

я бы не согласиться с altCognito и сказать, что одна из главных целей упокоения Слабая связь. Единый интерфейс, стандартные типы носителей и HATEOAS объединяются для создания чрезвычайно слабосвязанного интерфейса.

В ответ на комментарий Давида:

REST это все о супер-слабосвязанных до точки, где оно бессмысленно провайдер попытаться предвидеть все потребности клиентов

Фактически, REST ограничивает возможности клиентов, предоставляя только действительные ссылки в представлениях. В рамках этих ограничений клиент может попытаться удовлетворить свои собственные потребности. Это путем удаления знаний от клиента, когда могут быть сделаны определенные запросы, которые вы достигнете свободной связи. Свободное соединение не достигается, перечисляя набор ресурсов и говоря «хорошо, вы можете GET, PUT, POST, DELETE все, что хотите».