salary - architecture software

Ideal.NET arquitectura?

Question

Estoy escribiendo esta pregunta desde el punto de vista de una aplicación ASP.NET. Sin embargo, me doy cuenta de que también puede adaptarse a otros contextos.

Hay tantos enfoques para desarrollar los elementos comunes de un sitio web ASP.NET. Aquí hay algunos que he encontrado:

• LLBLGen
• Subsónico
• LINQ a SQL
• Marco de la entidad
• CodeSmith + .netTiers
• NHibernate
• Codificación manual DAL / BLL / Presentación

No me considero un desarrollador experto de ninguna manera, sin embargo, entiendo bien las técnicas comunes de programación orientada a objetos (POO) y puedo superar todos mis proyectos sin problemas. Sin embargo, me cuesta saber cómo "diseñar" un sitio. Con eso, quiero decir, ¿debería usar la arquitectura n-tier ? ¿Sigue siendo el estándar de oro y las herramientas anteriores solo utilizan ese concepto? Estoy bastante seguro de que quiero detenerme en MVC hasta un lanzamiento futuro (o final).

***** Editar: he eliminado la parte de la pregunta que trata sobre patrones (singleton, fábrica) después de haber comprendido más completamente la separación de la pregunta. Gracias por todos los que han respondido esta parte hasta ahora, sin embargo, mi enfoque principal está en la parte de arquitectura. *****

Editar # 2: cambié el título para ser más una pregunta agnóstica al darme cuenta de que esto se aplicaría a más de la arquitectura específica de la web.

Pregunta: ¿Qué pasos debo dar como primer paso, cuando me he sentado frente a un lienzo en blanco (archivo de solución) con toda mi documentación escrita y los requisitos del sistema en la mano? ¿A dónde voy desde allí?

Answer 1

No descartaría ASP.NET MVC.

La versión candidata saldrá en enero y, sorprendentemente, esta vez Microsoft parece estar siguiendo el verdadero significado de RC y, a menos que se encuentren errores de tope, también se creará la versión RTM.

Enlazar

Answer 2

Una pregunta tan amplia (y buena). Respiracion profunda.

No quitarte los patrones de diseño, pero son las tácticas en comparación con la estrategia de la arquitectura. Aprenderlos, por supuesto, pero eso no es especialmente pertinente aquí.

Muchas de las cosas que menciona en la pregunta no son mutuamente excluyentes y podrían considerarse subtrategias para secciones específicas de la arquitectura general. Mis preferencias personales han cambiado enormemente con el tiempo y con la experiencia, y sigo siendo completamente ingenuo con alguna tecnología fascinante, pero creo que solo hay una constante global de la arquitectura:

Separación de preocupaciones .

Este principio es su "estándar de oro", creo, que informa muchas cosas buenas: pruebas unitarias, diseño por contrato, inyección de dependencia, MVC, n-tier. Digo que el primer paso es comprender SoC y el segundo es actuar con un desarrollo basado en pruebas. Todo lo demás creo que tiene sus pros y sus contras, pero los beneficios del mantenimiento, la concepción y una arquitectura impulsada por el reconocimiento de los problemas primero están fuera de toda duda.

Mi carpeta de favoritos no es lo que pensé que era, pero estas son algunas de las piezas en línea que solidificaron mis opiniones sobre este tema:

• La importancia de SoC
• Introducción a TDD
• Más sobre TDD
• Pieza de IBM en la arquitectura de referencia

Editar: ¿dónde empiezas con el lienzo en blanco?

Agregue su biblioteca de prueba de unidad de su elección y esboce las pruebas (también conocido como hechos).

Prueba> Diseño> Código> Ir a 1

Answer 3

Creo que cada uno de los métodos que ha descrito tiene sus ventajas y desventajas. Lo que elijas será una cuestión de preferencia personal, las experiencias de los integrantes de tu equipo y el tipo de proyecto: Linq2Sql es excelente para comenzar a funcionar rápidamente, pero podría no ser el más adecuado para un proyecto empresarial grande y / o complejo, por ejemplo .. lo mejor que puedes hacer es probar algunos y llegar a conocerlos.

En cuanto a los patrones, ayudan a resolver problemas específicos y recurrentes de una manera comprobada. También ayudan a familiarizarse con los desarrolladores que no escribieron el código. Como se mencionó anteriormente, vale la pena probar algunos para tener una idea de lo que hacen y cuándo usarlos, pero son soluciones a problemas específicos de programación en lugar de patrones arquitectónicos.

Mi proceso de trabajo típico se ejecuta:

• Crear un modelo de entidad lógica
• Crear el almacenamiento de datos para el modelo de entidad
• Crear el código de acceso a datos y los objetos comerciales
• Crea la capa lógica / empresarial
• Crea la capa de presentación

Normalmente dividiría Acceso a los datos y Business Objects, Business Logic y Presentation (sitio web / winforms) en sus propios proyectos, además de todo lo que pueda desear volver a utilizar en una fecha posterior también se incluye en su propio proyecto. También tengo un proyecto base que contiene extensiones e interfaces comunes que reutilizo en casi todo lo que hago.

En términos de arquitectura, intento asegurar que mis proyectos se acoplen holgadamente para que pueda pasar fácilmente de una arquitectura de tres niveles a n niveles. El acoplamiento suelto también significa que puede cambiar su tienda de respaldo y todo lo que tiene que hacer es escribir una nueva capa de acceso a datos con toda su lógica y código de presentación sin modificar.

Creo que es importante no preocuparse demasiado por el nivel tres y el nivel n . Si separa sus inquietudes de forma adecuada, extender su sistema en varios niveles en una fecha posterior no será un ejercicio difícil.

Answer 4

Personalmente, soy un fanático de la arquitectura n-tier. Cuando empiezo, normalmente crearé dos proyectos para una aplicación web, el primero para Business Logic y Database Access, este es un proyecto de biblioteca de clase. Luego agrego un proyecto de aplicación web para el sitio web real.

En el pasado, construí un marco de acceso a datos que uso que aprovecha el Bloque de aplicaciones de datos de Microsoft para todo acceso a datos, y eso es lo que uso para estructurar todas las llamadas de datos.

A veces he usado Codemith u otros artículos, pero hasta ahora, he encontrado mejor suerte, simplemente estoy migrando mi propio código, ya que puedo obtener más granularidad con los datos. Si tuviera tiempo para investigar otras herramientas de ORM, es posible que no deba preocuparme por ello ...

Encuentro que el mejor enfoque es típicamente crear sus objetos comerciales, validación de datos y todas las piezas de "negocios" de la aplicación. Luego programe en las piezas de acceso a datos, y termine juntando todo junto con el código de presentación al final. Se necesita disciplina para poder hacer esto, pero asegura que estás construyendo cosas de una manera que pueda volver a usarse, y he tenido un gran éxito.

El libro al que hizo referencia podría ser un buen ejemplo para comenzar también.

Adición de comentario

En respuesta a un comentario publicado. Normalmente, dentro de mi biblioteca de clase Business / Data voy a usar espacios de nombres para separar la lógica de los datos. Algunas cosas clave se hacen aquí.

1. Mis llamadas a métodos de datos tienen un alcance limitado para el ensamblado, NO son elementos que se pueden llamar directamente, de esta manera hago cumplir el acceso a los datos a través de la lógica de negocios para todas las personas que llaman a la presentación.

2. Toda la entrada y salida de datos se realiza a través de objetos, en lugar de DataSets o cualquier otra variante

3. Los métodos comerciales después de la validación invocarán métodos específicos de los componentes de datos para obtener la información necesaria.