Diseño de software y diseño de servicios web

Question

Estoy a punto de diseñar mi API de servicios web, la mayoría de las funciones de mi API son básicamente muy similares a las de mi aplicación web.

Ahora la pregunta es, ¿debería crear 1 único método y volver a utilizarlos para la aplicación web y la API del servicio web? (Esta parece ser la solución lógica, sin embargo es muy complicada, es mucho más fácil duplicar el método utilizado por la aplicación web y mantener ambos separados, es decir, un método para la aplicación web y un método para el servicio web)

¿Cómo lo hacen?

1) Reutilización: un método principal y volver a utilizarlos tanto para aplicaciones web y aplicaciones de servicios web (me gusta esto, pero es complicado)

• WebAppMethodX --uses -> COMMONFUNCTIONMETHOD_X
• APIMethodX - --uses ----> COMMONFUNCTIONMETHOD_X

es decir Commonfunctionmethod_x contiene el conjunto reutilizable de características comunes

PRO: menos código, menos mantenimiento, menos errores.

CON: muy complicado

2) duplicado: dos métodos, un método para la aplicación web y un método para el servicio web.

• WebAppMethodX
• APIMethodX

PRO: sencilla

CON: la duplicación = más código, más mantenimiento, más errores!

Answer 1

Es probable que su caso de uso sea diferente para su API de servicio web público que para su API de aplicación interna. Cree un proyecto/nivel de servicio común y use ese mismo nivel tanto desde su aplicación web como desde su API pública de servicios web. Cree un método http invocable por separado para cada una de sus aplicaciones web y su servicio web.

Todo se reduce a estar allí

1) diferentes problemas de seguridad. Por ejemplo, es bueno (a menudo necesario) proporcionar una aplicación de cliente de muestra que haga uso de su API pública para que otros puedan ponerse al día rápidamente con lo que ha proporcionado. Esa API de cliente puede necesitar pasar las construcciones de objetos que usted les proporciona que han sido despojadas de lógica/contenido interno y seguro.(Recuerde que compilado C# podría ser texto claro con Reflector!)

2) diferentes necesidades y limitaciones. Por ejemplo, en el caso de una llamada a una aplicación interna, algunas veces se aplicarán diferentes reglas comerciales frente a su API pública de servicios web (a menudo, esta última se ve mucho más limitada por el alcance).

Si diseña su lógica de negocio en su capa de servicio e invoca bien esas clases/métodos desde su proyecto web y su proyecto de servicio web, tendrá mucha reutilización de código sin intentar complicar demasiado las cosas mezclando el uso casos.

Answer 2

Un método, en el servicio web, y haga que su aplicación web lo llame.

No entiendo qué significa "un método principal" para ambos. Las aplicaciones web no tienen un método principal; están implementados en un servidor de aplicaciones.

Otro punto a tener en cuenta: debe escribir su servicio en términos de una interfaz POCO. Una vez que haces eso, la implementación se convierte en una elección que realizas.

Answer 3

Un método. De lo contrario, cuando encuentres un error y lo arregles en uno, entonces olvídalo en el otro ... llorarás.

Answer 4

Depende ..

Normalmente, los separaría. De esta forma, se elimina la interdependencia entre dos procesos de alto nivel. la reutilización de código es buena dentro de un proceso, pero a veces se desea poder utilizar una aplicación diferente en el mismo servicio.

Si los dos son altamente dependientes entre sí, sin embargo, querrá volver a utilizar las mismas funciones para que al cambiarlo en un lugar lo cambie en otro. Evitando así más problemas potenciales con el proceso de desarrollo.