utilizando los principios de SOA más OOD en el código de servicio no

Question

Nuestro arquitecto ha hablado sobre el uso de técnicas de SOA a través de nuestra base de código, incluso en interfaces que no estén alojados en realidad como un servicio. Una de sus peticiones es que diseñemos nuestros métodos de interfaz para que no hagamos suposiciones sobre la implementación real. Entonces, si tenemos un método que toma un objeto y necesita actualizar una propiedad en ese objeto, explícitamente necesitamos devolver el objeto del método. De lo contrario, nos basaríamos en el hecho de que Algo es un tipo de referencia y C# nos permite actualizar las propiedades en un tipo de referencia por defecto.

Así:

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

    something.SomethingID = 42; 
} 

se convierte en:

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

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

realmente no puedo conseguir mi cabeza alrededor de los beneficios de este enfoque y se preguntaba si alguien podría ayudar?

¿Es este un enfoque común?

Answer 1

Creo que su arquitecto está intentando que su código tenga menos efectos secundarios. En su ejemplo específico, no hay un beneficio. En muchos, muchos casos, su arquitecto estaría en lo cierto, y puede diseñar grandes partes de su aplicación sin efectos secundarios, pero un lugar donde esto no puede suceder es durante las operaciones contra una base de datos.

Lo que hay que hacer es familiarizarse con la programación funcional, y se preparan para sus conversaciones sobre casos como estos con su arquitecto. Recuerde que sus intenciones probablemente sean buenas, pero los casos específicos son SU dominio. En este caso, el efecto secundario es el punto, y lo más probable es que desee un tipo de retorno de bool para indicar el éxito, pero devolver un nuevo tipo no tiene sentido.

Demuestre a su arquitecto que entiende que se limitan los efectos secundarios, pero se deben permitir ciertos efectos secundarios (base de datos, IU, acceso a la red, etc.) y es probable que esté de acuerdo con usted. Encuentre una forma de aislar los efectos secundarios deseados y explíqueles a él o ella, y esto ayudará a su caso. Su arquitecto probablemente lo apreciará si lo hace en un espíritu de colaboración (no tratando de hacer agujeros en su plan).

recursos

Un par de FP:

1. A great tutorial on Functional Programming
2. Wikipedia's entry on Functional programming

Buena suerte, espero que esto ayude.