Ideal .NET Architecture?

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í están algunos que he encontrado:

• LLBLGen
• SubSonic
• LINQ a SQL
• de Entity Framework
• CodeSmith + .netTiers
• NHibernate
• mano DAL codificación/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 (OOP) y puedo realizar todos mis proyectos sin problemas. Sin embargo, me cuesta saber cómo "diseñar" un sitio. Con eso, quiero decir, ¿debería usar n-tier architecture? ¿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 entendido 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. *****

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

---

Pregunta: ¿Qué pasos debo tomar como primer paso, cuando me he sentado delante de un lienzo en blanco (archivo de solución) con todos mis requisitos de pre-escritas sistema de documentación y en la mano? ¿A dónde voy desde allí?

Answer 1

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 forma 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 funciona:

• crear un modelo de entidad lógica
• Crear el almacenamiento de datos para el modelo de entidad
• Crear el código de acceso de datos y Business Objects
• Crear la lógica/capa empresarial
• Crear la capa de presentación

Normalmente dividiría Acceso a datos y Business Objects, Business Logic y Presentation (sitio web/winforms) en sus propios proyectos, además de todo lo que pueda querer 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 que no se obsesione con el tres frente n nivel - si separa sus preocupaciones se extienden adecuadamente su sistema a través de múltiples niveles en fecha posterior, no será un ejercicio difícil.

Answer 2

Personalmente, soy un entusiasta 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 he construido un marco de acceso a datos que utilizo 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.

He utilizado a veces el codesmith u otros artículos, pero hasta el momento, 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 ORM, es posible que no tenga que preocuparme por ello ...

Creo que el mejor enfoque es crear sus objetos comerciales, validación de datos y todo el "negocio" piezas 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 que ha mencionado puede ser un buen ejemplo para comenzar también.

adición del 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. mi método datos de las llamadas son todos de alcance limitado a la asamblea, no son elementos que se pueden llamar directamente, de esta manera hago cumplir acceso a datos a través de la lógica de negocio para todas las personas que llaman presentación

2. Todos 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 llamarán a métodos específicos de los componentes de datos para obtener la información necesaria.

Answer 3

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

No se puede quitar de 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 de alguna tecnología fascinante, pero creo que solo hay una constante global de arquitectura:

Separación de preocupaciones.

Creo que este principio es su "estándar de oro", 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 marcadores no es lo que yo pensaba que era, pero estas son algunas de las piezas en línea que se solidificó mi opinión sobre este asunto:

• The importance of SoC
• Intro to TDD
• More on TDD
• IBM piece on Reference Architecture

---

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

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

prueba > > Diseño Código > Goto 1

Answer 4

Yo no descartaría ASP.NET MVC.

La versión candidata saldrá a la venta 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 hará la versión RTM.

Link