Использование принципов SOA над OOD в не-сервисном коде

Question

Наш архитектор говорил об использовании методов SOA во всей нашей кодовой базе, даже на интерфейсах, которые на самом деле не размещаются как сервисы. Один из его запросов заключается в том, что мы разрабатываем наши методы интерфейса, чтобы не делать предположений о фактической реализации. Поэтому, если у нас есть метод, который получает объект и должен обновить свойство этого объекта, нам явно необходимо вернуть объект из метода. В противном случае мы будем полагаться на тот факт, что Something является ссылочным типом, а c # позволяет обновлять свойства ссылочного типа по умолчанию.

Итак:

public void SaveSomething(Something something)
{
  //save to database

  something.SomethingID = 42;
}

становится:

public Something SaveSomething(Something something)
{
  //save to database

  return new Something
  {
    //all properties here including new primary key from db
  };
}

Я не могу осмыслить преимущества этого подхода, и мне было интересно, может ли кто-нибудь помочь?

Это общий подход?

Answer 1

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

Что вам нужно сделать, так это познакомиться с функциональным программированием и подготовиться к беседам о подобных случаях с вашим архитектором. Помните, что его / ее намерения, скорее всего, хорошие, но конкретные случаи - это ВАША область. В этом случае побочным эффектом является точка , и вы, скорее всего, захотите, чтобы возвращаемый тип bool указывал на успех, но возвращать новый тип не имеет смысла.

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

Пара ресурсов для FP:

1. Отличный учебник по функционалу Программирование
2. Википедия о функциональном программировании

Удачи, надеюсь, это поможет.