Programacion Modular

"_Ivaj_" escribió en el mensaje
news:

Hola:
Estoy intentando hacer un programa en vb .net en una solucion con diversos
modulos.
Me dijeron en un curso que hice que es mejor hacer las aplicaciones lo mas
modulares posibole de manera que para posteriores actualizaciones no fuese
necesario mas que que hacer cambios en la clase que fuese generar la dll y
actualizar.
El caso es que tengo una solucion con multiples proyectos de libreria de
clases pero al generar me esta volviendo loco con las referencias.
Me gustaria saber si a alguien mas le ha pasado y como puedo evitarlo.

Hola, Javier:

Como en todo, tambien en el diseño de software la corrección está en el
balance. En un extremo está escribir el programa como una sola función,
lleno de gotos (suena a broma, pero en un tiempo se hacian asi); y en el
otro estaría escribir cada funcion o cada forma en una DLL (eso si que nunca
se ha visto). Muy cerca de ese extremo está colocar cada clase en una DLL.

El software se agrupa jerárquicamente por capas, según su grado de
generalidad. En el esquema clásico tienes tres capas: servicios de interfaz
de usuario, que incluye todo lo que son formularios de entrada o
presentación; servicios de negocios, responsable de implementar los procesos
y las reglas de validación y -al fondo- el nivel de acceso a datos (que yo
prefiero llamar las "clases de dominio"): definen las propiedades comunes de
todos los objetos del dominio (clientes, proveedores) e implementan los
mecanismos de persistencia (generalmente guardarse/recuperarse de una BBDD).

Cada nivel debe estar separado de los demas, previendo su distribución en
diferentes equipos.

Adicionalmente, en cada nivel puede haber grupos de clases que dependan
entre si: las facturas y los detalles de factura, por ejemplo, son una
dependencia practicamente inevitable. En la medida en que toda factura se
relaciona con un cliente, tienes una dependencia estructural entre clientes
y facturas, y si bien es posible utilizar un programa para facturar detalles
sin relacion con nada, lo normal es que los detalles de las facturas hagan
referencia a un "producto", que como minimo tiene un código asociado con una
descripción y uno o mas precios. Aunque las técnicas modernas -sobre todo
para desarrolladores individuales o pequeños grupos- te permiten diseñar a
medida que construyes (de modo que puedes comenzar a "escribir el programa"
sin haber hecho un solo diagrama), es bueno determinar las interdependencias
entre clases, sobre todo para permitirlas sólo cuando resulte
imprescindible.

Un conjunto de clases unidas por algun tipo de dependencia (en la practica,
si un miembro de la clase "A" hace referencia a la clase "B", entonces "A
depende-de B") constituye un "paquete", y un "paquete" es la mínima unidad
de distribución.

Existen técnicas para reducir la dependencia entre clases, normalmente
descritas (las tecnicas) como patrones de diseño. Pero antes de meterte en
esas profundidades (hay unos cuantos conceptos entre "me dijeron ... que es
mejor hacer las aplicaciones lo más modulares posible" y la literatura sobre
patrones de diseño) la recomendación es que determines las relaciones entre
las clases y agrupes todas las que están interconectadas en una DLL para
cada "red de interdependencias".

Estoy seguro de que te sorprenderas de la maraña que tienes :-)

Salud, y Feliz Navidad!