Este artículo proviene de un motor de traducción automática.

Patrones y prácticas

Puede depender Patterns and Practices

Alex Homer

Contenido

Patrones y prácticas
Una guía disponible
Coping con la abstracción
Un breve historial de dependencia en Microsoft
Ampliar Yourself
Resumen

Escribir código de equipo solía ser extremadamente difícil.Cuando empezó a equipos domésticos de programación más años que encarga recordar, la única manera de que un programa ejecutado en más de un rastreo desultory fue escribir con código máquina.Incluso una utilidad de procesamiento de textos sencillo puede tardar varias semanas para crear como que meticulously había planeado las asignaciones de memoria para las variables, escribió rutinas para realizar tareas simples como caracteres de dibujo en la pantalla y teclado descodificación de entrada y, a continuación, escribe cada instrucción de procesador individual en un ensamblador.

Hoy en día, en comparación, crear código eficaz es fácil.Nos dar por sentado la gran cantidad de herramientas, solicitudes de los lenguajes de alto nivel, marcos de tiempo de ejecución, las bibliotecas de código y servicios de sistema operativo que hacen lo posible crear aplicaciones rápida y eficazmente.Sin embargo, al crear el código ha convertido en mucho más sencillo, la tarea de creación de aplicaciones no lo tiene.Esperamos mucho más de nuestras aplicaciones modernas que nunca.Se debe comunicar a través de redes, interactuar con otras aplicaciones y servicios, exponer interfaces de usuario muy interactivos y con capacidad de respuesta y admitir multimedia enriquecidas y gráficos.Y, por supuesto, la deben ser estable, segura, confiable y fácil de administrar.

De hecho, sería casi imposible cumplir los requisitos de demandado de nuestras aplicaciones modernas sin el continuo crecimiento y evolución de lenguajes de programación, sistemas operativos, servicios de la plataforma y marcos de trabajo.El gran aumento de complejidad de estas aplicaciones también ha obligado nos para descubrir formas de simplificar y organizar el código.En los años, un número de técnicas de programación y diseño probadas y probados ha evolucionado, como la creación de componentes, orientación de objetos, y, más recientemente, orientación de servicios.

Patrones y prácticas

Mientras mejoras en las herramientas y marcos de hacerlo más fácil escribir código más rápidamente y moderno idiomas y los estilos de programación facilitan escribir mejor código, el área de una que ha tenido el impacto de la mayoría de los en nuestra capacidad para crear aplicaciones en los últimos 10 a 15 años ha sido la evolución y la aceptación creciente de patrones de diseño de software.

Patrones de diseño describen problemas comunes que se produzcan repetidamente en diseño de la aplicación y el desarrollo y proporcionan técnicas para tratar estos problemas.Modelos también describen el ejercicio del sector actual para resolver los problemas de arquitectura y para el tratamiento de solicitar la complejidad del diseño de aplicaciones.La disposición de elementos de código y la solución es en el corazón de diseño de software hoy en día y patrones nos proporciona modos de simplificar y organizar estos elementos, que proporciona la mejor oportunidad para maximizar rendimiento, flexibilidad y capacidad de mantenimiento para aplicaciones.

Desde el lanzamiento de la libreta novedosa por la Gang de cuatro, Erich gamma, Richard Helm, Johnson Ralph y Juan M..Vlissides, patrones de diseño: Elements of Reusable Object-Oriented software (Addison-Wesley, 1996), que documentado muchos de los patrones de diseño básico que tomamos por sentado hoy en día, el número de patrones de diseño disponibles para los desarrolladores y diseñadores ha crecido a un ritmo excepcional.Prácticamente todos los aspectos de la creación de software tiene asociados a modelos de diseño y la implementación y simplemente documentar todos los ha convertirse en una tarea imposible.En su lugar, los diseñadores y desarrolladores tienden a fragmentar en specialties y obtenga información acerca los modelos más aplicables a su propia área de experiencia.

Una guía disponible

En 2002, el grupo de patrones y prácticas de Microsoft Corporation publicado la arquitectura de aplicaciones para .NET: Guía de diseño de aplicaciones y servicios, reuniendo los consejos de orientación y el especialista en de diseño básica para ayudar a los arquitectos crear aplicaciones de Microsoft .NET Framework.Sin embargo, las tecnologías de cambiar a lo largo del tiempo y mientras los fundamentos de diseño y se describe en la guía de desarrollo son igualmente válidos hoy en día, la guía original no abarcan algunos de las nuevas capacidades de .NET Framework o solucionar los problemas de diseño que surjan para nuevos tipos de aplicaciones.

Durante los últimos varios meses, un grupo amplio de especialistas de la industria y expertos en la materia, tanto dentro como fuera de Microsoft, ha sido colaborar para crear una nueva edición de la guía que proporciona una introducción completa a la arquitectura y diseño de soluciones de Microsoft .NET Framework.La Guía de arquitectura de aplicaciones de Microsoft (2ª edición) describe principios de arquitectura de alto nivel y modelos y pensar actual en aceptado prácticas recomendadas de diseño y desarrollo.También incluye instrucciones sobre aplicar estos factores a tipos específicos de las aplicaciones, y proporciona una amplia introducción del muchos servicios de plataforma y las bibliotecas de código disponibles para facilitar la implementación.

Por supuesto, para pedir prestado una frase utiliza a menudo, arquitectura de software y del sistema es algo que comprende la pregunta de vida, el universo y todo el contenido.No sola publicación puede responder todas las posibles preguntas o con el objetivo proporcionar cobertura completamente completa de todos los escenarios posibles.Sin embargo, la nueva guía objetivo es proporcionar la información que necesite si es sólo comenzado fuera designing.NET aplicaciones basadas en Framework, un diseñador experimentado mover a .NET Framework desde otra plataforma, un arquitecto realizado busca información específica y consejos, o simplemente le interesa obtener más información sobre los escenarios amplia y las oportunidades que ofrece .NET Framework.

Coping con la abstracción

Para ilustrar recomendaciones del sector, la guía enumera los principios generales que se deben aplicar al diseñar casi cualquier tipo de aplicación.Estos principios son mantener la separación de los problemas, uso abstracción para implementar flexible acoplamiento entre capas y componentes, implementar capacidades de ubicación de servicio y administrar crosscutting aspectos como el registro y la seguridad.Aunque estos pueden parecer ser deseables, pero no tiene ninguna relación con objetivos, una técnica puede ayudarle a aplicar fácilmente varios principios de diseño.El principio de la inversión de dependencia implica la separación de los problemas mediante las abstracciones en lugar de implementaciones concretas.En términos de patrones de diseño, puede lograr esto aplicando el modelo de inversión de control (IoC) y su patrón relacionada, inyección de dependencia (DI).

La teoría es bastante sencilla.En lugar de especificar el tipo concreto real que cada clase o componente utilizará para realizar alguna actividad o proceso en tiempo de diseño, se organizan para que estas clases o componentes para recuperar el objeto correspondiente de un contenedor que previamente había configurado con asignaciones de tipo y registrar tipos.Por ejemplo, tal como se muestra en la aplicación simple en la figura 1 , el componente de acceso a datos puede requerir los servicios de un componente de registro.Como se ha correctamente abstrae el código crosscutting desde el código específico de tareas y específica de la aplicación, puede tener varios componentes de registro entre los que elegir.Quizá uno está diseñado para su uso cuando Depure la aplicación, otra para uso cuando que ejecuta la aplicación internamente en su propia red, y una tercera más adecuado para ejecución en un sistema de nivel de empresa que hace uso de un entorno de supervisión, como Microsoft System Center.

La figura 1 una aplicación sencilla que hace uso de capas y un separar el registro de componentes

Incluso podría ser el caso de que tenga varios datos acceso a componentes, cada uno de ellos diseñados para su uso en un entorno determinado o con un tipo de almacén de datos diferente.Por lo tanto, la capa empresarial se debe elegir el componente de nivel de datos adecuado dependiendo de la implementación actual o el entorno en tiempo de ejecución.De forma similar, puede tener servicios que su aplicación utiliza varias veces, como un mensaje de correo electrónico envío de servicio o un servicio de transformación de datos.Inyección de dependencia puede actuar como un recurso de ubicación de servicio para ayudar a la aplicación recuperar una instancia (ya sea una instancia nueva o una instancia existente) del servicio en tiempo de ejecución.

Cada uno de estos ejemplos eficazmente describe una dependencia de una parte de la aplicación en otro y resolver estas dependencias de manera que no perfectamente combine los objetos es el objetivo del principio de la inversión de dependencia.

Un breve historial de dependencia en Microsoft

Aunque los principios de inversión de dependencia han sido alrededor durante un largo periodo de tiempo, características para ayudar a los desarrolladores a implementarlo en las aplicaciones que se ejecutan en la plataforma de Microsoft son relativamente recientes.De hecho, hay un artículo que un desarrollador renowned en el mundo Java, cuando se visita la sede de Microsoft, observó que era la creencia general que nadie en Microsoft podría escribirse inyección de dependencia. Aunque es decir, sin duda, un mito urbano, es el caso de que herramientas para ayudar a los desarrolladores que implementan muchos de los patrones comunes no han sido una prioridad en la mayoría de los áreas de la compañía.

Sin embargo, el grupo de patrones y prácticas de Microsoft destaque a través de nuestra posición único del que se está dentro de la compañía sino fuera de los equipos de desarrollo de producto principal y las divisiones.El objetivo de p & p, tal como se muestra por nuestro subtítulo "demostrado recomendaciones para los resultados previsibles," es proporcionar a los desarrolladores instrucciones, herramientas, bibliotecas, marcos de trabajo y un sinfín de otras instalaciones para ayudarles a diseñar y generar aplicaciones mejor en la plataforma de Microsoft.Un rápido vistazo a nuestropágina principal de MSDNse ilustran la variedad amplia de los activos que proporcionamos.

Entre estos activos se varios productos que utilizar del patrón de inyección de dependencia, incluidos Enterprise Library, marcos de aplicación compuesta y las fábricas de software.Durante el desarrollo de estos activos, en concreto el original compuesto aplicaciones bloque (CAB), quedó claro que era necesario un mecanismo de inyección de dependencia reutilizables y altamente configurable, y por lo que el equipo creó la versión original del Generador de objetos.

Generador de objeto es casi totalmente configurable y ahora se utiliza en una amplia gama de productos en p & p y en otros lugares dentro de Microsoft.Sin embargo, es muy difícil de utilizar.Requiere una gran muchos parámetros que tienen objetos complejos, y se expone una gama de eventos que se deben controlar para aplicar la configuración que necesita.Intenta inicial documento Generador de objetos como parte del proyecto CAB pronto revela que esto iba a ser una tarea uphill.Además, el Generador de objetos era bastante más de un contenedor de inyección de dependencia, y parecía excesivo en términos de los requisitos comunes de implementación de los patrones DI y IoC.

Durante el desarrollo de Enterprise Library 4.0, se actualizó el Generador de objetos, no para simplificar, pero para que sea más rápido y eficaz.También se ajustar para su uso en el mecanismo de inserción primero dependencia principales de Microsoft que está dirigido a los desarrolladores que deseen implementar los modelos de DI y IoC Encuadrando.Generador de objeto es la base de unidad, un contenedor de inyección de dependencia ligera y extensible que es compatible con inyección de constructor, inserción de la propiedad y la inserción de llamada de método.

Unidad proporciona capacidades para creación de objetos simplificado, especialmente para las estructuras de objeto jerárquicos y las dependencias; abstracción de requisitos en tiempo de ejecución o a través de la configuración; simplifica la administración de crosscutting problemas; y aumenta la flexibilidad mediante aplazar la configuración del componente al contenedor.Tiene una capacidad de ubicación de servicio y permite a los clientes almacenar o el contenedor de caché, incluso en las aplicaciones Web de ASP.NET.

Desde el lanzamiento de la primera versión unidad de 2008 anticipado, encontró una casa en muchos p & p activos como el mecanismo predeterminado para implementar la inversión de dependencia.Unidad también ha continuado evolucionar mientras restante compatible con versiones anteriores; se puede utilizar para habilitar las características de Enterprise Library, así como para utilizarlo como un contenedor de DI independiente.En la versión más reciente, ofrece instalaciones para implementar instancia y la interceptación de tipo (mediante una extensión de complemento) que permiten las implementaciones de aspecto orientada A programación técnicas, como la inserción de directiva.

Unidad también genera otras implementaciones de contenedor DI dirigidas a tareas específicas y requisitos, como una implementación muy ligera diseñada para usar en dispositivos móviles y teléfonos inteligentes.Mientras tanto, planificadas desarrollos futuros en el terreno de unidad y biblioteca de empresa incluyen características para abrir Enterprise Library a otros mecanismos de contenedor de terceros, además de proporcionar extensiones adicionales que permiten nuevas capacidades de unidad.Aplicar la inversión de dependencia

¿Dejar este distracción histórico y volver a la aplicación hipotética, cómo puede aplicar el principio de la inversión de dependencia para lograr los objetivos, que se ha explicado anteriormente, de separación de problemas, abstracción y acoplamiento flexible?La respuesta es configurar un contenedor de inyección de dependencia, como unidad, con los tipos adecuados y escriba las asignaciones y permitir que la aplicación recuperar y insertar las instancias de los objetos correspondientes en tiempo de ejecución.la figura 2 ilustra cómo se puede utilizar el bloque de aplicaciones de unidad para implementar este contenedor.En este caso, se rellene el contenedor con las asignaciones de tipo entre las definiciones de interfaz para los componentes de datos y componentes de registro y las implementaciones concretas específicas de estas interfaces que desea que la aplicación que se va a utilizar.

La Figura 2 la inyección de dependencia puede seleccionar los componentes adecuados en tiempo de ejecución según la configuración del contenedor.

En tiempo de ejecución, la capa empresarial consultará el contenedor para recuperar una instancia del componente de nivel de datos correctos, dependiendo de su asignación actual.El nivel de datos, a continuación, consultará el contenedor para obtener una instancia del componente Registro adecuada, dependiendo de la asignación almacenado para dicho tipo de interfaz.Como alternativa, los datos y los componentes de registro pueden heredar de respectivas clases base y pueden asignar los registros en el contenedor entre estos tipos base y los tipos concretos heredados.

Este enfoque condicionada por el contenedor para resolver tipos e instancias significa que el desarrollador es libertad para cambiar las implementaciones para los datos y los componentes de registro, siempre y cuando estas implementaciones ofrecer la funcionalidad necesaria y exponen la interfaz apropiada (por ejemplo, mediante implementa la interfaz asignada o hereda de la clase base asignada).La configuración del contenedor puede establecerse en el código en tiempo de ejecución mediante métodos de contenedor que registran tipos, las asignaciones de tipo o las instancias existentes de los objetos.Como alternativa, puede llenar el contenedor al cargar los registros de un origen de configuración o un archivo, como el archivo web.config o el archivo app.config.

Cuando desea registrar más de una instancia de un tipo, puede utilizar un nombre para definir cada uno y, a continuación, resolver los distintos tipos mediante la especificación del nombre de la.El registro también puede especificar la duración del objeto, facilitando la tarea de conseguir capacidades de estilo de la ubicación de servicio mediante el registro el objeto de servicio como un singleton o con una duración específica, como por subproceso.El ejemplo de código siguiente muestra algunos ejemplos de registrar las asignaciones de tipo con el contenedor:

C#
// Register a mapping for the CustomerService class to the IMyService interface. 
myContainer.RegisterType<IMyService, CustomerService>();

// Register the same mapping using a mapping name. 
myContainer.RegisterType<IMyService, CustomerService>("Data");

// Register the first mapping, but as a singleton. 
myContainer.RegisterType<IMyService, CustomerService>(
                         new ContainerControlledLifetimeManager());

Nota: los ejemplos de código de referencia clases y tipos con sólo el nombre de clase. Puede utilizar definiciones de alias de tipo en el archivo de configuración a alias los nombres de tipo completo de las clases, que simplifica el contenedor registro cuando esté usando un archivo de configuración.

Para recuperar la instancia de un objeto, simplemente consultar el contenedor especificando el tipo, el tipo de interfaz, o el tipo de clase base (y el nombre), si ha registrado el tipo utilizando un nombre como se muestra en el ejemplo siguiente. El contenedor resuelve el tipo, si está registrado y crea o devuelve una instancia del objeto correspondiente. Si no está registrado, el contenedor simplemente crea una nueva instancia de ese tipo y entrega al. ¿Por qué haría resolver los elementos a través del contenedor cuando no hay ningún registro para ese tipo? La idea es aprovechar las características adicionales y muy útiles que unidad y muchos otros DI contenedor mecanismos, proporciona, la posibilidad de insertar objetos mediante constructor, propiedad establecedor y inserción de llamada de método.

C#
// Retrieve an instance of the mapped IMyService concrete class. 
IMyService result = myContainer.Resolve<IMyService>();
// Retrieve an instance by specifying the mapping name. 
IMyService result = myContainer.Resolve<IMyService>("Data");

Por ejemplo, cuando se crea una instancia de un objeto a través del contenedor, unidad examina los constructores y insertará automáticamente las instancias del tipo adecuado en los parámetros de constructor. Volver a nuestro ejemplo de aplicación simple anterior, el componente de acceso a datos puede tener un constructor que toma una referencia a un componente de registro como un parámetro. Si este tipo de parámetro es la interfaz o clase base para registrar componentes registrados con el contenedor, unidad se resuelve el tipo asignado, crear una instancia y se pasa al constructor del componente de datos (como se muestra en la figura 3 ). No hace nada salvo registrar las asignaciones.

La figura 3 la inserción de objetos en parámetros de constructor

C#
// In main or startup code:
// Register a mapping for a logging component to the ILogger interface.
// Alternatively, you can specify this mapping in a configuration file. 
myContainer.RegisterType<ILogger, MyLogger>();

...

// In data access component:
// Variable to hold reference to logger.
private ILogger _logger = null;

// Class constructor. Unity will populate the ILogger type parameter.
public DataAccessRoutines(ILogger myLogger)
{
  // store reference to logger
  _logger = myLogger;
  _logger.WriteToLog("Instantiated DataAccessRoutines component");
}

Esto significa que puede cambiar el tipo concreto real que la aplicación utiliza simplemente cambiando la configuración del contenedor, bien en tiempo de diseño, en Ejecutar tiempo si modifica la configuración o dinámicamente en función de algún valor que su código recopila desde el entorno y se utiliza para crear o actualizar la asignación en el contenedor. Que puede conecte su componente de registro de depuración cuando sea necesario o conectar un nuevo componente registro "súper rápida" cuando encuentre la que el anterior es demasiado lenta. Mientras tanto, el administrador del sistema puede actualizar la configuración según sea necesario para supervisar, administrar y adaptar el comportamiento de la aplicación en tiempo de ejecución para entornos de cambio de palo y problemas operativos.

Del mismo modo, si tiene una dependencia entre dos objetos, como la dependencia de una vista en su instructor al implementar el modelo Model-View-Presenter (MVP), puede utilizar la inyección de dependencia para debilitar el acoplamiento entre estas clases. Simplemente definir una propiedad de la clase de vista como el tipo de moderador o un tipo de clase base y, marca la propiedad con una dependencia de atributos, como se muestra en el ejemplo siguiente:

C#
// Variable to hold reference to controller.
private IPresenter _presenter;

// Property that exposes the presenter in the view class. Unity will inject 
// this automatically because it carries the Dependency attribute.
 [Dependency]
public IPresenter MyViewPresenter
{
  get { return _presenter; }
  set { _presenter = value; }
} 

Nota: los atributos son la forma más rápida para especificar propiedades se deben insertar.Si desea no aparezca utilizar atributos (para evitar acoplamiento las clases en el contenedor) se puede utilizar un archivo de configuración o la API de unidad para especificar qué propiedades se deben insertadas.

Cuando se crea la vista mediante la resolución, a través del contenedor, unidad se detectar el atributo de dependencia, automáticamente resolver una instancia de la clase de moderador concretos apropiado y establecerla como el valor de propiedad de la clase de vista.En el ejemplo Inicio rápido se incluye con la unidad muestra este enfoque en una aplicación de Windows Forms.En realidad se resuelve el formulario principal de la aplicación a través del contenedor, que hace que la unidad crear y rellenar varias dependencias en toda la aplicación completa, utilizando constructor y propiedad establecedor inserción.

Ampliar Yourself

Unidad proporciona una gran cantidad de funcionalidad relacionadas con el DI, pero siempre hay algo adicional que desee conseguir.El desafío con unidad fue mantenerlo genérica para satisfacer el número máximo de requisitos, mientras se extensible para que lo pueda adaptarse a sus propios requisitos específicos.Esto se logra mediante extensiones de contenedor, que permiten hacer casi nada en términos de administración de creación de objetos y recuperación.

Como ejemplo, la inicia rápido incluida con la unidad Demuestre una extensión de contenedor que implementa un mecanismo de Publish\Subscribe de condicionada por el atributo simple.Como unidad crea instancias de objetos, cables controladores de eventos para ellos según los atributos de los archivos de clase.Otro ejemplo genera información de registro detallada cuando se crea o recupera cada tipo de a través del contenedor, lo que ayuda al depurar el aplicaciones complejas.

Esta flexibilidad gran incluye sobre ya unidad permite interactuar con el mecanismo de generador de objetos subyacente a través de la extensión de contenedor.AH, que puede decir, pero el Generador de objetos es muy difícil de utilizar y no está totalmente documentado.De hecho, la documentación de la unidad contiene información sobre el Generador de objetos en términos de cómo se interactúa con él de una extensión de contenedor y los ejemplos de inicio rápido proporcionan gran cantidad de código de ejemplo que puede utilizar y modificar.

Resumen

Existen muchas vistas en la arquitectura de aplicación y el diseño.El 42010:2007 estándar ISO/IEC/IEEE 1471 "recomendado práctica para arquitectura de descripción de un uso intensivo de software sistemas" describe la arquitectura de software como "la organización de un sistema plasmado en sus componentes, sus relaciones entre sí y para el entorno y los principios guiar su diseño y la evolución fundamental".Sin embargo, en su libro patrones de aplicación arquitectura empresarial (Addison-Wesley, 2002), Martin Fowler dice que ".. .in al final, arquitectura reduce a que el material importante es, " que es una manera mucho más sencilla de capturar el espíritu de arquitectura de software.

La Guía de arquitectura de aplicaciones de Microsoft (2ª edición) le ayudará a comprender qué es el material importante para que se pueden crear mejor, aplicaciones de calidad superiores más rápida y más eficazmente.Como ha visto en este artículo, un área específica, aprovechar los patrones de inyección de dependencia y inversión de control, puede ayudarle a lograr muchos de los objetivos de diseño promovidos por la Guía.Esto incluye la separación de los problemas, el uso de abstracción para implementar el acoplamiento flexible entre niveles, la ubicación del servicio y la implementación de características de administración mejorada de crosscutting preocupaciones.

Alex homer es ingeniero de documentación de trabajar con el equipo de patrones y prácticas de Microsoft.Sus ravings aleatorios sobre vida, tecnología y el mundo en general pueden encontrarse enhttps://blogs.msdn.com/alexhomer/ .