¿Cómo llamaría usted a physcially separados código UI / BL en solución ASP.NET?

Question

Capítulo 19: Niveles de Física e implementación en MSDN describe "Distributed implementación"(véase la Figura 2). Todo esto está muy bien.

En mi experiencia que siempre hemos desplegado nuestros sistemas basados ??en la web de acuerdo con lo que describen como "no distribuidas de despliegue" (figura 1). Mi opinión es que en el mundo de Microsoft el "Application Server" como una cosa separada en realidad no existe (como lo hace en el mundo Java) porque es efectivamente 'cuece en' al OS / Windows.

Así que mi pregunta es si se va a distribuir el interfaz de usuario y la lógica de negocios (BL) en diferentes servidores / niveles, ¿cómo iban a comunicar?

Sé que una respuesta es utilizar una "capa de servicio" - ¿Cuáles son las alternativas? ¿Cómo realmente hacer eso? ¿Qué aspecto tendría desde una perspectiva código?

Answer 1

En primer lugar. No lo haga. Simplemente no lo hacen. Usted se encontrará con un mundo de dolor. capas lógicas y físicas son cosas diferentes. separación lógica de los niveles de la aplicación es una idea buena. La separación física de los niveles de la aplicación es más a menudo que no es una receta para el desastre. Si hay una razón despliegue bueno (procesador de pagos compartida en otro cuadro), seguro, adelante. Se pueden utilizar los mecanismos estándar que todos conocemos y amamos - WCF, MSMQ, HTTP, ... Escoja su veneno. Pero no tome la sobrecarga y la complejidad por el bien de la altura de un ideal mítico en un libro blanco de MSDN.

Answer 2

Servidores de aplicaciones se cocinaron como una idea para ayudar ración de un recurso escaso: potencia informática en el nivel medio. Esta idea vino de la tierra de mainframe, en un principio, cuando la CPU era escasa y cara, y por lo tanto una gran cantidad de tiempo y esfuerzo y dinero se gastó en cubitos la CPU unidad central a varios usuarios, el acelerador de carga de trabajo, manteniendo la carga de la base de datos, "pasivación "transacciones hasta que la carga disminuida después de las horas, y así sucesivamente. En aquellos días la gente gastaron millones de dólares en software que mantiene la pista de las transacciones en el mainframe, con el fin de poder llevar a cabo "de cargo" - costo interno que representa el uso de la expen $ ive mainframe. Sí, la gente pasó barcos cargados de dinero para que pudieran hacer la facturación a los departamentos internos para el uso de la computadora central.

La cosa es, Intel (y más tarde AMD), Cisco (y otros), EMC, Microsoft, Linux y rindió toda la discutible idea. La informática se volvió barata. Muy barato. No hay realmente, realmente, realmente no hay necesidad de recursos de cómputo ración de nivel medio. ¿Qué es un ir servidor de doble CPU para estos días? ¿Cuántos de los que se puede desplegar para el sueldo anual de un chico de TI? Esta es una inversión de la vieja economía de los ordenadores centrales, en los que el cálculo era caro, recurso escaso, y la gente era relativamente (!!) barato. Ahora las personas son la parte más costosa, y el cálculo es barato.

servidores de aplicaciones, y todas las campanas y silbatos que tienen para restringir el acceso a la computación, o parcelación a cabo, o estrangulamiento o incluso "seguimiento" transacciones para fines de devolución de cargo .... estas cosas no son necesarios cuando se tienen bastidores de servidores de AMD baratos.

Otra cosa servidores de aplicaciones hicieron fue proteger la base de datos de carga de trabajo. En esencia, el trabajo sacar datos desde el servidor db. Hubo un tiempo, desarrolladores de poner la lógica de negocio en un procedimiento almacenado y, boom, se produjo su aplicación. Pero había problemas de escalabilidad con este enfoque. Ahora, sin embargo, procedimientos almacenados son rápidos y eficientes. servidores de bases de datos puedan ampliar, a bajo precio. Lo más probable es, usted no tiene uno de los volúmenes de carga de trabajo top-100 en el mundo que no pueden ser soportados en el hardware de Intel, con la lógica de procedimiento almacenado.

Un problema importante con el enfoque de procedimiento almacenado sin embargo, es que todavía es algo difícil de autor procedimientos almacenados en idiomas principales (Java, C #, VB, etc), y gestionarlos. Sí, sé de SQL CLR y Java VM gestionado por el PP. Pero esos no son los enfoques convencionales. Además, la base de datos de administración no le gusta jinetes de código que ensucian sus gráficos de utilización. Por estas razones, todavía hay un deseo de la lógica de negocio de escritura en una lengua separada dedicada a este fin. Y todavía hay un deseo de ejecutar y administrar que la lógica de los recursos informáticos dedicados. Pero ... un "servidor de aplicaciones" tradicional ?? No, no tiene sentido.

Ponga toda su lógica en un servidor de Intel y permitir rasgar er! Si necesita más escala, clonar la caja. Toda la lógica del negocio es sin estado (¿verdad?), Para que pueda escalar. Utilice 3 máquinas "aplicación" de servidores, o 4 o 5 o sin embargo muchos que necesita. Todos corriendo exactamente el mismo código. Clones unos de otros. Sin importar cuántos Business Machines lógica que tiene, no distribuir la carga de trabajo física. Para escalabilidad máximo, se esfuerzan por mantener cada transacción en una sola caja. Esa es una receta para la eficiencia y el uso óptimo de los recursos.

Es una buena práctica utilizar capas lógicas en su arquitectura de aplicaciones. Esto hace que sea más fácil de desarrollar y mantener. Pero no suponga que la separación lógica debe implicar, o incluso recomendar, separación física. No es asi.