Una opinion sobre objetos

Personalmente creo que darte una opinion sin conocer el proyecto es un poco
descabellado.

Desde mi punto de vista el estudio previo de un proyecto de gran embergadura
lleva su tiempo, y hay que definir muchos matices... Sin conocer el proyecto
considero que es imposible darte una opinion.

Lo unico que te puedo decir es que el uso de DLLs esta muy bien en los
siguientes casos:

1) Biblioteca de controles genericos. Te permite emplear dichos controles en
tu aplicacion, asi como en otras aplicaciones, pudiendo depurar dicha parte
del codigo en un menor tiempo.
2) Controles y/o funciones compartidas por varios modulos. Crea un unico
punto conflictivo y reduce el tiempo de depuracion.
3) Darle una mayor flexibilidad al programa por medio de plugins.

En definitiva, es una buena opcion cuando el codigo es reutilizable. Si el
codigo contenido en una DLL es especifico para un unico programa no le veo
la ventaja. Quizas lo unico podria ser tenerlo mas "modularizado", para
futuras depuraciones y/o modificaciones... Aun asi eso dependera de como
hayas documentado el programa. En principio si tienes un diagrama de los
diferentes ficheros indicando claramente su funcionabilidad (No hablo de
exes y dlls sino de codigo fuente), deberia ser tan sencillo localizar los
codigos como si editasemos el fuente de una DLL.

Pero esto es solo una opinion (y ando un poco dormido)

"Sergio T" escribió en el mensaje
news:

Hola

estoy desarrollando un sistema bastante grande y tengo la siguiente duda

Tengo varios subsistemas importaciones, inventarios,contabilidad,...

la

pregunta es como organizo la capa de negocios?

Estoy definiendo un proyecto de biblioteca de clases por cada subsistema
aunque esto tiene la dificultad de que tendre objetos que deben ser usados
en otros subsistemas por tanto pienso establecer referencias entre las
distintas dlls que les parece? manteniendo un unico namespace por dll o
proyecto

Por otro lado estaba pensando crear un solo proyecto gigante en el cual
tenga direfentes namespaces aunque creo que es demaciada cantidad de

clases

en una sola biblioteca de clases y no se cual sera el impacto en el
rendimiento. que opinan???


gracias por las sugerencias

Hola Juan Pedro

Estoy de acuerdo contigo en que para desarrollar un proyecto importante
primero hay que analizar/diseñar/programar la cuestion es la ssiguiente

Tengo el programa analizado, estoy utilizando como herramientas conceptuales
de diseño los diagramas de clases ssun la metodologia O.O. de E.Yourdon,
apoyado tambien con E.R. para mi base de datos, el tema es que no estoy del
todo convencido a la hora de pensar en el lenguaje de implementacion y caer
en el diseño de la programación y la estructuracion de todas las clases en
los distintos componentes de la capa de negocios, los cuales se comvertiran
en dlls . En cuanto a la capa de usuario no tengo mayores problemas en su
implementacion igual en la capa de datos. por ejemplo que consideraciones de
desempeño debo tomar en cuenta para separar mis clases en distintas dlls? o
que tan facil será implementar modificaciones al sistema en produccion

gracias

"Juan Pedro Gonzalez" escribió en el mensaje
news:

Personalmente creo que darte una opinion sin conocer el proyecto es un

poco

descabellado.

Desde mi punto de vista el estudio previo de un proyecto de gran

embergadura

lleva su tiempo, y hay que definir muchos matices... Sin conocer el

proyecto

considero que es imposible darte una opinion.

Lo unico que te puedo decir es que el uso de DLLs esta muy bien en los
siguientes casos:

1) Biblioteca de controles genericos. Te permite emplear dichos controles

en

tu aplicacion, asi como en otras aplicaciones, pudiendo depurar dicha

parte

del codigo en un menor tiempo.
2) Controles y/o funciones compartidas por varios modulos. Crea un unico
punto conflictivo y reduce el tiempo de depuracion.
3) Darle una mayor flexibilidad al programa por medio de plugins.

En definitiva, es una buena opcion cuando el codigo es reutilizable. Si el
codigo contenido en una DLL es especifico para un unico programa no le veo
la ventaja. Quizas lo unico podria ser tenerlo mas "modularizado", para
futuras depuraciones y/o modificaciones... Aun asi eso dependera de como
hayas documentado el programa. En principio si tienes un diagrama de los
diferentes ficheros indicando claramente su funcionabilidad (No hablo de
exes y dlls sino de codigo fuente), deberia ser tan sencillo localizar los
codigos como si editasemos el fuente de una DLL.

Pero esto es solo una opinion (y ando un poco dormido)

"Sergio T" escribió en el mensaje
news:
> Hola
>
> estoy desarrollando un sistema bastante grande y tengo la siguiente duda
>
> Tengo varios subsistemas importaciones, inventarios,contabilidad,...
la
> pregunta es como organizo la capa de negocios?
>
> Estoy definiendo un proyecto de biblioteca de clases por cada subsistema
> aunque esto tiene la dificultad de que tendre objetos que deben ser

usados

> en otros subsistemas por tanto pienso establecer referencias entre las
> distintas dlls que les parece? manteniendo un unico namespace por dll o
> proyecto
>
> Por otro lado estaba pensando crear un solo proyecto gigante en el cual
> tenga direfentes namespaces aunque creo que es demaciada cantidad de
clases
> en una sola biblioteca de clases y no se cual sera el impacto en el
> rendimiento. que opinan???
>
>
> gracias por las sugerencias
>
>

Hola,

Como no se como has planificado el proyecto te comento lo que suelo hacer
yo...

Por un lado tengo una serie de DLLs con codigo reutilizable. Por ponerte un
ejemplo, una de estas librerias contiene la variacion del ListView con la
implementacionpara el orden y el ajuste de columnas, asi mismo contiene una
serie de "etiquetas" con una serie de estilos que considero utiles y un
panel con sombreado, etc... Estos controles los suelo reutilizar con
bastante frecuencia en varios proyectos, por lo que los tengo aislados en
una DLL. Esto me permite incluirlos en el proyecto on bastante sencillez, y
al incluirlo en varios proyectos cualquier fallo, mejora, etc... de uno de
estos controles se puede exportar a cualquiera de los otros productos. De la
misma forma tengo alguna DLL con controles que suelo emplear menos
frecuentemente, y en este caso las ordeno por tematicas... Por ejemplo una
DLL con controles orientados a tal actividad.

Por otro lado algunas aplicaciones que he tenido en mis manos son modulares
(En este caso compuestas por varios ejecutables segun departamentos). En
este caso puedes encontrarte tras el analisis que todas las aplicaciones
requieren la misma (o practicamente la misma) autenticacion. En este caso
suelo crear una DLL con las funciones de autenticacion, asi como el
formulario de autenticacion. Que logro con esto? Cualquier fallo en la
autenticacion, validaciones, etc... esta en un fichero, y realizando una
unica modificacion he modificado todos los modulos. Es decir, en vez de
tener X puntos de conflicto lo reduzco a uno.

Otro motivo que se me ocurre para crear una DLL es por el lenguaje de
programacion. Normalmente cuando estas desarrollando se espera (o por lo
menos las empresas esperan) que todo este unificado en un unico lenguaje de
programacion... pero en ocasiones esto es imposible, o simplemente
"incompatible" con la aplicacion. La imposibilidad se podia ver mas
claramente en el VB6, donde para completar algunas funciones era necesario
recurir a una DLL normalmente creada en C++... y cuando hablo de
"incompatibilidad", me refiero a que en ocasiones un lenguaje de
programacion se muestra mas rapido y por lo tanto mas eficaz para desmpeñar
ciertas operaciones, y si tenemos una operacion critica que requiere
velocidad, implicaria que debemos elegir la opcion mas adecuada (y si no
coincide con el lenguaje de programacion que estamos usando personalmente lo
considero una incompatibilidad entre lso requisitos y el lenguaje empleado,
pero simplemente por llamarlo de alguna forma).

Otro motivo que puede llamar al uso de DLLs es proporcionar al programa la
opcion de plugins alli donde lo consideres necesario. Por ejemplo, en
algunos casos nos pueden decir que les interesa poder exportar los datos a
Access, pero nosotros podemos preever que en un futuro igual les interesa
exportar los datos a Excell, o a otro programa, de esta forma podemos
separar el codigo de la exportacion a Access en una DLL (Plugin) de tal
forma que en un futuro tan solo debamos escribir el plugin pertinente para
amoldarnos a sus cambios.

Evidentemente todo esto deberia estar contemplado en el estudio del
proyecto... Ya que puede que en el proyecto inicial solo tengamos una
aplicacion que ataque una base de datos, o lo que sea... Pero igual en un
futuro nos pueden pedir otras aplicaciones que hagan cosas parecidas e
incluso secciones identicas. Todas las secciones que pudiesen ser identicas
podrian ir aisladas en una DLL para ahorarnos trabajo en las futuras
aplicaciones, y lo que es mas importante, poder modificar una linea de
codigo y corregir de esta forma un problema, u optimizar ambas aplicaciones.
Vamos, que parte del estudio seria saber que codigo se va a repetir, que
codigo se puede reutilizar en otras aplicaciones, que grado de
extensibilidad queremos dar a la aplicacion, y preveer un poco el futuro.

No se si esto te servira de mucha ayuda...

Saludos



"Sergio T" escribió en el mensaje
news:

Hola Juan Pedro

Estoy de acuerdo contigo en que para desarrollar un proyecto importante
primero hay que analizar/diseñar/programar la cuestion es la ssiguiente

Tengo el programa analizado, estoy utilizando como herramientas

conceptuales

de diseño los diagramas de clases ssun la metodologia O.O. de E.Yourdon,
apoyado tambien con E.R. para mi base de datos, el tema es que no estoy

del

todo convencido a la hora de pensar en el lenguaje de implementacion y

caer

en el diseño de la programación y la estructuracion de todas las clases en
los distintos componentes de la capa de negocios, los cuales se

comvertiran

en dlls . En cuanto a la capa de usuario no tengo mayores problemas en su
implementacion igual en la capa de datos. por ejemplo que consideraciones

de

desempeño debo tomar en cuenta para separar mis clases en distintas dlls?

o

que tan facil será implementar modificaciones al sistema en produccion

gracias

"Juan Pedro Gonzalez" escribió en el mensaje
news:
> Personalmente creo que darte una opinion sin conocer el proyecto es un
poco
> descabellado.
>
> Desde mi punto de vista el estudio previo de un proyecto de gran
embergadura
> lleva su tiempo, y hay que definir muchos matices... Sin conocer el
proyecto
> considero que es imposible darte una opinion.
>
> Lo unico que te puedo decir es que el uso de DLLs esta muy bien en los
> siguientes casos:
>
> 1) Biblioteca de controles genericos. Te permite emplear dichos

controles

en
> tu aplicacion, asi como en otras aplicaciones, pudiendo depurar dicha
parte
> del codigo en un menor tiempo.
> 2) Controles y/o funciones compartidas por varios modulos. Crea un unico
> punto conflictivo y reduce el tiempo de depuracion.
> 3) Darle una mayor flexibilidad al programa por medio de plugins.
>
> En definitiva, es una buena opcion cuando el codigo es reutilizable. Si

el

> codigo contenido en una DLL es especifico para un unico programa no le

veo

> la ventaja. Quizas lo unico podria ser tenerlo mas "modularizado", para
> futuras depuraciones y/o modificaciones... Aun asi eso dependera de como
> hayas documentado el programa. En principio si tienes un diagrama de los
> diferentes ficheros indicando claramente su funcionabilidad (No hablo de
> exes y dlls sino de codigo fuente), deberia ser tan sencillo localizar

los

> codigos como si editasemos el fuente de una DLL.
>
> Pero esto es solo una opinion (y ando un poco dormido)
>
> "Sergio T" escribió en el mensaje
> news:
> > Hola
> >
> > estoy desarrollando un sistema bastante grande y tengo la siguiente

duda

> >
> > Tengo varios subsistemas importaciones, inventarios,contabilidad,...
> la
> > pregunta es como organizo la capa de negocios?
> >
> > Estoy definiendo un proyecto de biblioteca de clases por cada

subsistema

> > aunque esto tiene la dificultad de que tendre objetos que deben ser
usados
> > en otros subsistemas por tanto pienso establecer referencias entre las
> > distintas dlls que les parece? manteniendo un unico namespace por dll

o

> > proyecto
> >
> > Por otro lado estaba pensando crear un solo proyecto gigante en el

cual

> > tenga direfentes namespaces aunque creo que es demaciada cantidad de
> clases
> > en una sola biblioteca de clases y no se cual sera el impacto en el
> > rendimiento. que opinan???
> >
> >
> > gracias por las sugerencias
> >
> >
>
>

Hola Juan Pedro

Gracias por tus sugerencias, siempre son utiles todas las ideas cuando uno
comienza con un lenguaje en serio.

Salu2
Sergio



"Juan Pedro Gonzalez" escribió en el mensaje
news:

Hola,

Como no se como has planificado el proyecto te comento lo que suelo hacer
yo...

Por un lado tengo una serie de DLLs con codigo reutilizable. Por ponerte

un

ejemplo, una de estas librerias contiene la variacion del ListView con la
implementacionpara el orden y el ajuste de columnas, asi mismo contiene

una

serie de "etiquetas" con una serie de estilos que considero utiles y un
panel con sombreado, etc... Estos controles los suelo reutilizar con
bastante frecuencia en varios proyectos, por lo que los tengo aislados en
una DLL. Esto me permite incluirlos en el proyecto on bastante sencillez,

y

al incluirlo en varios proyectos cualquier fallo, mejora, etc... de uno de
estos controles se puede exportar a cualquiera de los otros productos. De

la

misma forma tengo alguna DLL con controles que suelo emplear menos
frecuentemente, y en este caso las ordeno por tematicas... Por ejemplo una
DLL con controles orientados a tal actividad.

Por otro lado algunas aplicaciones que he tenido en mis manos son

modulares

(En este caso compuestas por varios ejecutables segun departamentos). En
este caso puedes encontrarte tras el analisis que todas las aplicaciones
requieren la misma (o practicamente la misma) autenticacion. En este caso
suelo crear una DLL con las funciones de autenticacion, asi como el
formulario de autenticacion. Que logro con esto? Cualquier fallo en la
autenticacion, validaciones, etc... esta en un fichero, y realizando una
unica modificacion he modificado todos los modulos. Es decir, en vez de
tener X puntos de conflicto lo reduzco a uno.

Otro motivo que se me ocurre para crear una DLL es por el lenguaje de
programacion. Normalmente cuando estas desarrollando se espera (o por lo
menos las empresas esperan) que todo este unificado en un unico lenguaje

de

programacion... pero en ocasiones esto es imposible, o simplemente
"incompatible" con la aplicacion. La imposibilidad se podia ver mas
claramente en el VB6, donde para completar algunas funciones era necesario
recurir a una DLL normalmente creada en C++... y cuando hablo de
"incompatibilidad", me refiero a que en ocasiones un lenguaje de
programacion se muestra mas rapido y por lo tanto mas eficaz para

desmpeñar

ciertas operaciones, y si tenemos una operacion critica que requiere
velocidad, implicaria que debemos elegir la opcion mas adecuada (y si no
coincide con el lenguaje de programacion que estamos usando personalmente

lo

considero una incompatibilidad entre lso requisitos y el lenguaje

empleado,

pero simplemente por llamarlo de alguna forma).

Otro motivo que puede llamar al uso de DLLs es proporcionar al programa la
opcion de plugins alli donde lo consideres necesario. Por ejemplo, en
algunos casos nos pueden decir que les interesa poder exportar los datos a
Access, pero nosotros podemos preever que en un futuro igual les interesa
exportar los datos a Excell, o a otro programa, de esta forma podemos
separar el codigo de la exportacion a Access en una DLL (Plugin) de tal
forma que en un futuro tan solo debamos escribir el plugin pertinente para
amoldarnos a sus cambios.

Evidentemente todo esto deberia estar contemplado en el estudio del
proyecto... Ya que puede que en el proyecto inicial solo tengamos una
aplicacion que ataque una base de datos, o lo que sea... Pero igual en un
futuro nos pueden pedir otras aplicaciones que hagan cosas parecidas e
incluso secciones identicas. Todas las secciones que pudiesen ser

identicas

podrian ir aisladas en una DLL para ahorarnos trabajo en las futuras
aplicaciones, y lo que es mas importante, poder modificar una linea de
codigo y corregir de esta forma un problema, u optimizar ambas

aplicaciones.

Vamos, que parte del estudio seria saber que codigo se va a repetir, que
codigo se puede reutilizar en otras aplicaciones, que grado de
extensibilidad queremos dar a la aplicacion, y preveer un poco el futuro.

No se si esto te servira de mucha ayuda...

Saludos



"Sergio T" escribió en el mensaje
news:
> Hola Juan Pedro
>
> Estoy de acuerdo contigo en que para desarrollar un proyecto importante
> primero hay que analizar/diseñar/programar la cuestion es la ssiguiente
>
> Tengo el programa analizado, estoy utilizando como herramientas
conceptuales
> de diseño los diagramas de clases ssun la metodologia O.O. de E.Yourdon,
> apoyado tambien con E.R. para mi base de datos, el tema es que no estoy
del
> todo convencido a la hora de pensar en el lenguaje de implementacion y
caer
> en el diseño de la programación y la estructuracion de todas las clases

en

> los distintos componentes de la capa de negocios, los cuales se
comvertiran
> en dlls . En cuanto a la capa de usuario no tengo mayores problemas en

su

> implementacion igual en la capa de datos. por ejemplo que

consideraciones

de
> desempeño debo tomar en cuenta para separar mis clases en distintas

dlls?

o
> que tan facil será implementar modificaciones al sistema en produccion
>
> gracias
>
> "Juan Pedro Gonzalez" escribió en el mensaje
> news:
> > Personalmente creo que darte una opinion sin conocer el proyecto es un
> poco
> > descabellado.
> >
> > Desde mi punto de vista el estudio previo de un proyecto de gran
> embergadura
> > lleva su tiempo, y hay que definir muchos matices... Sin conocer el
> proyecto
> > considero que es imposible darte una opinion.
> >
> > Lo unico que te puedo decir es que el uso de DLLs esta muy bien en los
> > siguientes casos:
> >
> > 1) Biblioteca de controles genericos. Te permite emplear dichos
controles
> en
> > tu aplicacion, asi como en otras aplicaciones, pudiendo depurar dicha
> parte
> > del codigo en un menor tiempo.
> > 2) Controles y/o funciones compartidas por varios modulos. Crea un

unico

> > punto conflictivo y reduce el tiempo de depuracion.
> > 3) Darle una mayor flexibilidad al programa por medio de plugins.
> >
> > En definitiva, es una buena opcion cuando el codigo es reutilizable.

Si

el
> > codigo contenido en una DLL es especifico para un unico programa no le
veo
> > la ventaja. Quizas lo unico podria ser tenerlo mas "modularizado",

para

> > futuras depuraciones y/o modificaciones... Aun asi eso dependera de

como

> > hayas documentado el programa. En principio si tienes un diagrama de

los

> > diferentes ficheros indicando claramente su funcionabilidad (No hablo

de

> > exes y dlls sino de codigo fuente), deberia ser tan sencillo localizar
los
> > codigos como si editasemos el fuente de una DLL.
> >
> > Pero esto es solo una opinion (y ando un poco dormido)
> >
> > "Sergio T" escribió en el mensaje
> > news:
> > > Hola
> > >
> > > estoy desarrollando un sistema bastante grande y tengo la siguiente
duda
> > >
> > > Tengo varios subsistemas importaciones, inventarios,contabilidad,...
> > la
> > > pregunta es como organizo la capa de negocios?
> > >
> > > Estoy definiendo un proyecto de biblioteca de clases por cada
subsistema
> > > aunque esto tiene la dificultad de que tendre objetos que deben ser
> usados
> > > en otros subsistemas por tanto pienso establecer referencias entre

las

> > > distintas dlls que les parece? manteniendo un unico namespace por

dll

o
> > > proyecto
> > >
> > > Por otro lado estaba pensando crear un solo proyecto gigante en el
cual
> > > tenga direfentes namespaces aunque creo que es demaciada cantidad de
> > clases
> > > en una sola biblioteca de clases y no se cual sera el impacto en el
> > > rendimiento. que opinan???
> > >
> > >
> > > gracias por las sugerencias
> > >
> > >
> >
> >
>
>