¿Deberíamos llamar a la API web desde la aplicación MVC en la misma solución?

Estoy trabajando en un proyecto en MVC que tiene una aplicación móvil, por lo que una cosa es clara: tenemos que usar la API web para que pueda usarse en la aplicación móvil.

Después de crear API cuando comenzamos a desarrollar el sitio web, estamos confundidos y discutimos sobre si usar API o acceder directamente al objeto Business. Y terminamos después de tener una opinión de un desarrollador más experimentado para consumir API web en lugar de usar el objeto Business directamente.

Estoy teniendo confusión con respecto a esta estructura de solución.

1) Por qué deberíamos usar la API web y hacer una solicitud HTTP (que lleva mucho tiempo) para obtener o colocar datos en lugar del objeto comercial directamente que está en la misma solución.

2) Después de tener argumentos, dijeron qué pasaría si el cliente desea alojar API y web en un servidor en la nube diferente y aplicar el escalado solo en API o puede querer tener una URL diferente para acceder a la API y la Web (que es algo lógico). Entonces, en ese caso, ¿deberíamos llamar a la API web desde la aplicación MVC en la misma solución?

3) Si estamos alojando API y Web en diferentes hosting, significa que nuestra Web usará WebClient y tendrá una llamada HTTP en cada navegación. ¿Es correcto?

4) Si vamos a hacer un objeto comercial desde la API y el alojamiento web en un servidor diferente, entonces, si algo cambia en BL, será necesario actualizar la compilación en ambos servidores.

5) O deberíamos crear un solo proyecto para API y podemos agregar vistas o páginas html para desarrollar una interfaz web para que de esa manera podamos llamar directamente a API desde ajax.

Según mi conocimiento, # 5 es la mejor solución o API es solo para acceso de terceros. Si tenemos DB, EF, capa de datos y capa empresarial en la misma solución, entonces no deberíamos usar API para hacer llamadas HTTP y acceder directamente a objetos comerciales. (corríjame si me equivoco) Se necesita API cuando la aplicación móvil o de escritorio o cualquiera quiere acceder a la aplicación para que podamos tener el mismo repositorio y la misma capa de datos.

En mi escenario, tengo que crear una API, ya que también tenemos una aplicación móvil, y en el lado de la API del proyecto llamamos capa empresarial (proyecto separado) y la capa empresarial se comunica con la capa de acceso a datos (proyecto separado). Entonces, mi pregunta es si alojamos nuestra API y nuestra web en diferentes servidores, entonces llamar a la API, que es una solicitud HTTP, puede tomar más tiempo en lugar de usar el método de la capa empresarial a medida que creamos el proyecto y tenemos .dll de la capa empresarial. En el controlador API, acabamos de convertir la venta de nuestro negocio a formato json.

He buscado en internet pero no obtuve una respuesta convincente. Encontré un blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx discutiendo el mismo punto pero nuevamente en ese blog, mi pregunta es ¿por qué debemos considerar el escenario # 3?

Actualización: podemos tener un proyecto API diferente y un proyecto MVC y podemos llamar a la API desde la web usando JavaScript o podemos usar el patrón MVVM.

Gran pregunta! Siempre estoy buscando una mejor manera de estructurar mis proyectos. Cada punto que planteas tiene mérito y después de haber explorado una variedad de estructuras de solución, debo decir que estoy de acuerdo con la mayoría de los comentarios aquí: no hay una solución perfecta. Algunas cosas que debe preguntarse ante este tipo de problema: ¿Qué tan compleja es esta aplicación? ¿Con cuántos sistemas necesitaré integrar, o cuántos sistemas necesitaré integrar con este sistema? ¿Cuántas pruebas planeo hacer? ¿Hay un equipo de diseño / interfaz de usuario separado? ¿Necesitaremos escalar? ¿Qué constituye una sesión?

Veamos un par de escenarios y formas de usar un poco de ingeniería inteligente para hacer que las cosas realmente exploten (y algunos trucos para hacer las cosas un poco más fáciles).

Hospedaje de API y sitio web en el mismo proyecto
En este caso, puede tener una solución única con cero o más proyectos de capa empresarial y un solo proyecto híbrido MVC / WebAPI (así como otros proyectos: utilidad, etc.).

Pro's
Everything está en un solo lugar. No es necesario tocar el claxon en mensajes complicados (llamadas HttpClient), puede tener un estado de sesión compartido (cliente y servidor a través de cookies, sesión InProc / OutOfProc, etc.), agrupación de conexiones, lógica compartida, etc. La implementación no podría ser más simple.

Con's
Everything está en un solo lugar. Esta es probablemente la estructura más monolítica posible. No hay interfaces claramente definidas entre sus capas. Termina con una alta cohesión . Los desarrolladores perezosos evitarán las interfaces al tratar con este tipo de arquitectura, lo que hace que las pruebas sean un gran dolor. Escalar / co-ubicar la aplicación será difícil.

Usos
Utilizaría esta estructura de proyecto para una aplicación única, interna o simple. ¿Está creando un sistema rápido para rastrear la inscripción en el campamento de baloncesto en la Y local? Esta es tu arquitectura!

WebAPI y sitio web en diferentes proyectos Tiendo
a preferir este caso. Usted tiene una solución única con uno (o más) proyecto (s) MVC y un proyecto WebAPI.

¡Modularización profesional ! ¡Bajo acoplamiento! Cada proyecto puede ser independiente, probarse por separado y puede administrarse de manera diferente. Esto le permite implementar más fácilmente diferentes estrategias de almacenamiento en caché según sus necesidades. Al mantener límites sólidos entre sus diferentes sistemas, puede establecer más fácilmente contratos que le permitan imponer patrones de uso específicos y reducir la posible fricción (lea: menos errores con menos oportunidades de abusar de la API). El escalado es un poco más fácil ya que solo necesita escalar los bits que están viendo una gran carga. La integración se vuelve un poco más fácil de manejar también porque necesitará tener una idea sobre cómo se verá su API desde el principio.

El
mantenimiento de Con es un poco más difícil. Múltiples proyectos significa que necesitará propietarios de proyectos / características para realizar un seguimiento de las fusiones, contratos (interfaces), implementaciones, etc. Mantenimiento del código, deuda técnica , seguimiento de errores, gestión del estado: todos se convierten en preocupaciones, ya que podrían necesitar implementarse de manera diferente según sus necesidades Este tipo de aplicaciones también requieren la mayor planificación y curación a medida que crecen.

¿Está
creando una aplicación que podría tener 100 usuarios hoy y 100,000 la próxima semana / mes? ¿La aplicación tiene que enviar notificaciones, administrar flujos de trabajo complejos y tener múltiples interfaces (web + aplicación móvil + SharePoint)? ¿Tienes mucho tiempo libre y te encanta resolver rompecabezas de más de 5000 piezas durante el fin de semana? ¡Esta es la arquitectura para ti!

Consejos
Una vez resumido lo anterior, puedo entender cómo su próximo proyecto podría parecer un poco desalentador. No se preocupe, aquí hay algunos trucos que he aprendido a lo largo de los años.

1. Intenta usar sesiones sin estado. En sistemas más pequeños, esto podría significar almacenar una cookie encriptada que contiene al menos la identificación interna del usuario actual y un tiempo de espera. Los sistemas más grandes pueden significar almacenar una cookie encriptada con una identificación de sesión simple que se puede obtener de un almacén de datos (redis, almacenamiento de tablas, DHT , etc.). Si puede almacenar suficiente información para no tener que acceder a la base de datos principal en cada solicitud, estará en un buen lugar, pero trate de mantener las cookies por debajo de 1k.
2. Tenga en cuenta que probablemente habrá más de un modelo. Trate de pensar en términos de modelos y proyecciones (los enlaces que encontré aquí eran ... no buenos ... piense: el artículo de inventario de un hombre es la línea de pedido de otro hombre, la misma estructura básica subyacente, pero diferentes puntos de vista). Algunos proyectos tienen un modelo diferente para cada límite lógico / conceptual (es decir, el uso de un modelo específico para la comunicación con una API específica.
3. API en todas partes! Cada vez que un objeto / clase / estructura expone cualquier dato o comportamiento, está estableciendo una API. Tenga en cuenta cómo otras entidades o dependencias utilizarán esta API. Piensa en cómo podrías probar esta API. Considere qué podría estar hablando con esta API (¿otros objetos a través del código? ¿Otros sistemas a través de un protocolo?) Y cómo se exponen esos datos (¿fuertemente tipeados? ¿JSON? * Tos * XML?).
4. Construya para lo que tiene, no para lo que imagina que tendrá dentro de dos años. Otra respuesta hace referencia a YAGNI : ¡son absolutamente correctos! Resolver problemas imaginarios hace que su fecha límite sea imaginaria. Establezca objetivos sólidos para sus iteraciones y cumpla con ellos. ¡Desplegar! Un proyecto en desarrollo es un proyecto con un solo usuario: ¡usted!
5. YMMV (su kilometraje puede variar). Aquí solo hay un absoluto: hay un problema, estás creando una solución. Todo lo demás está completamente en el aire. Ambas soluciones anteriores pueden convertirse en un gran éxito, y en un fracaso de succión. Todo depende de usted, sus herramientas y cómo las usa. ¡Camina a la ligera, compañero desarrollador!

Acceder directamente a sus objetos comerciales directamente (supongo que quiere decir en su controlador) será más rápido y fácil.

¿Qué sucede si el cliente desea alojar API y web en un servidor en la nube diferente y aplicar el escalado solo en la API o puede querer tener una URL diferente para acceder a la API y la Web (lo cual es algo lógico)

Entonces necesitarás alojarlos por separado ... pero eso no me parece muy lógico, seguramente querrás escalar ambos. ¿Estás seguro de que necesitas satisfacer este requisito? Eso suena como una exageración. Recuerde YAGNI: si no lo necesita, no lo construya. Cuando lo necesite, constrúyalo.

Si fuera yo, construiría el sitio utilizando la tecnología que mejor se adapta al sitio, entonces cuando (si) necesita un servicio que otras personas puedan llamar construir por separado.

Yo diría; prefiera MVC llamando a WebAPI a través de HTTPClient. Es abrumador ir en torno a la lógica "core dll", pero la principal ventaja es que su sistema general tendrá acceso de un solo punto a los objetos de dominio en HTTP ... De todos modos en el futuro ... con la recogida de Micro Service Architecture Y las aplicaciones que ya cambian a Marcos del lado del cliente (AngularJS, etc.) ... mejor tratar MVC como otro cliente ... y discipular a su equipo para administrar bien las API ...

MANTÉNGALO SIMPE. Espero que esto ayude. Gracias..