como defino el nombre de mis proyectos

Definir el nombre de nuestros proyectos parece una tonteria, si la empresa se llama XSoft, tendemos a ponerle a nuestros proyectos el nombre de nuestra empresa

Particularmente no me gusta por dos razones:
-que hacemos si la empresa cambia de nombre?- tendremos proyectos con un nombre de empresa anterior
-ademas ni de que hablar, si tenemos que vender la empresa por alguna causa y el supuesto cliente me dice que quiere comprar mis proyectos pero que no los quiere con ese nombre

el nombre de un proyecto de desarrollo, es subjetivo para cada uno, pero para mi es importante no hacer tan subjetivo el nombre por las razones expuestas

es solo un consejo qeu pueden tomar a la hora de definir nombres en sus proyectos

Saludos

Programacion en capas

la idea de capas es separar la interfaz, el negocio y los datos de la empresa, con la idea en mente que podria cambiar una de las capas y supuestamente modificar una parte sin afectar a las otras tambien se podria tener configurado la capa de datos en un lugar fisico, la capa de negocio en otro lugar fisico y la interfaz en otro


la otra idea de capas es un tema de organizacion estructural de los proyectos y no tener todo mezclado(interaz-negocio-datos)desde los inicios de la programacion y actualmente en las empresas que no se implementa capas se mezcla en la interfaz de usuario(winfom, web,etc) el diseño, el comportamiento de los formularios con el acceso a datos y la logica de negocio, con el tiempo la interfaz despues de tantas modificaciones que sufre queda llena de codigo que no se entiende

separar los tantos es bueno a nivel organizacional de los proyectos como para la duracion de estos en el tiempo pero hay que saber que, como y donde separar

capas:

- datos:
-acceso a datos con la base de datos(los metodos de las clases se comunican
con un proveedor de datos(sql, oracle, etc))
-transaccion por operacion
-negocio:
-en las clases de negocio se definen las validaciones de negocio y la llamada a la capa de datos
cada entidad fisica de la base(tablas) tendra una clase de negocio propia
y para el caso de entidades compuestas como comprobantes se crea una superclase que usa varias clases de negocio
- cuando tenemos una clase que actualiza varias tablas
tenemos que abrir una transaccion y cerrarla o cancelarla cuando termina de actualizar
la capa de negocio debe ser visible por la interfaz, ya sea windows o web


-contrato: la capa de contrato es la capa de transporte de datos entre una capa y la otra por ejemplo en la interfaz usas dataset para mostrar datos, para trabajar con datos y cuando tenes que pasarlos a la capa de negocio los pasas por un parametro del tipo dataset y asi a las demas capas. la capa de contrato debe ser visible por la capa interfaz y la capa de datos, otras forma de declarar ls objetos de transporte de datos ademas de dataset pueden ser, listas genericas, clases entidades, colecciones genericas

-interfaz:
windows, web, movile. es la capa de presentacion al usuario y hace uso de la capa de negocio
para obtener y actualizar datos a la base
en esta capa solo deberiamos tener aspectos de diseño, formularios y clases especificas del proyecto que desarrollamos




capas en un proyecto:

cada capa deberia corresponderse con un proyecto por ejemplo para las siguientes capas quedaria algo asi:

-presentacion
-negocio
-contrato
-datos

solucion net:
- proyecto interfaz tipo windows, web o movile
- proyecto negocio de tipo dll
- proyecto contrato de tipo dll
- proyecto datos de tipo dll

para todo lo que sea clases genericas, componentes y controles de usuario debemos crear una solucion aparte en un proyecto de tipo dll y agregar alli todas nuestras clases genericas que vamos a usar en todas o casi todas las aplicaciones

referencia entre proyectos:
la referencia de proyectos o dll sirve para poder hacer uso de los tipos
que tiene dicho proyecto(clases, controles, etc)
-en la capa de interfaz tenes que agregar como referencia
la capa de negocio y de contrato(agregas como referencia la dll que genera la compilacion del proyecto)
-en la capa de negocio tenes que agregar como referencia
la capa de datos

- si tenes un proyecto generico de clases genericas podes agregarla como referencia
en la capa que necesites, por ejemplo
si en tu capa de interfaz tenes que armar formularios a partir de un form base
que tenes en tu proyecto generico, lo agregas como referencia



dependencia entre proyectos:
la dependencia entre proyectos es para que net compruebe que proyecto debe generarse primero y si un proyecto ha cambiado que este se genere primero segun el orden de generacion

por ejemplo si tocaste la capa de negocio y haces el exe en la capa de interfaz si no tenes agregado el proyecto de negocio como dependencia al proyecto interfaz vas a generar el exe con una dll antigua

la dependencia en capas seria asi y el orden el siguiente

orden de generacion:
1-primero debe generarse la capa de datos
2-segundo generarse la capa de contrato
3-tercero generarse la capa de negocio
4-cuarto generarse la interfaz
asi el exe final tendra actualizada todas las dll

dependencia:
en este caso a la interfaz debo agregarle como dependencia los demas proyectos

interfaz:
-datos
-contrato
-negocio
-dll generica
al agregar una dependencia se genera una referencia del ensamblado
al proyecto que estamos agregando la dependencia y luego no se podria agregar como referencia en el emsamblado depedendiente
porque no se puede crear una referencia ciclica
para verlo mas claro, lo hacemos con el ejemplo:

-capa de datos: proyecto de tipo dll

-capa de negocio: proyecto de tipo dll
si agrego la capa de datos como referencia en la capa de negocio luego no podria agregar como referencia la capa de negocio en la capa de datos. con esto se ve que en la capa de datos no puedo usar o instancia objetos de la capa de negocio, pero en la capa de negocio si puedo usar e instancia objetos de la capa de datos
es importante definir las depedencias entre proyectos y el orden de generacion para que nuestro sistema trabaje siempre con las dll nuevamente compiladas si fueron modificadas y en el orden correcto


implementar capas es sin duda un trabajo mas costoso y que requiere
de mas capacitacion que la programacion tradicional y hay muchas formas
en internet de encarar capas, cada uno desde un punto de vista
todos son validos, algunos mas que otros, este es un enfoque que me
resulto despues de ver varios enfoques sobre capas

Diseño de Tablas en nuestra base de datos

Independientemente del tipo de motor en el que trabajemos, a la hora de diseñar una tabla siempre tenemos que tener una columna id unica que sea nuestra clave principal y parecera una tontera lo que digo pero he visto en algunas universidades y terciarios que no enseñan mucho sobre el diseño de bases de datos y sino agarren cualquier tesis de algun alumno y veran que al alumno no se le enseña a diseñar tablas ni bases

por ejemplo: si tenemos una tabla alumno tenemos que crear una columna id unica llamada por ejemplo idalumno y que sea incremental y otra columna tendra el dni del alumno pero jamas manejar la columna dnialumno como la columna clave en la tabla de alumnos y menos que menos en otra tabla
por ejemplo si tenemos las tablas de inscripciones alumnos y en ella metemos como parte de una clave el dni del alumno
todo muy lindo si el dni se cargo bien pero si despues de 5 meses te dicen que el dni estaba mal cargado tenes que actualizar cada tabla con el dni correspondiente manualmente o hacerlo por actualizaciones en cascada si hiciste la relacion de las tablas y se seteo que se haga actualizacion en cascada

pero a mi manera de ver siempre es conveniente no mezclar la clave fisica principal de una tabla que identifica cada registro con una clave restrictiva y logica como podria ser por dni de alumno, ya que dos alumnos no tendrian que tener el mismo dni entonces ahi si podemos crear un indice por dni y que sea unico pero que la clave principal no sea un dato de la entidad

La propiedad Nombre de los Controles y nombre de variables en nuestra aplicacion

Siempre sera una buena tecnica, trabajemos en el lenguaje que trabajemos de usar una forma estandar de llamar a nuestros controles en los formularios y a nuestros objetos en el codigo fuente

He visto muchas veces que la mayoria de los programadores usa los nombres por defecto cuando un control se inserta en un formulario ya sea web o windows
por ejemplo tirar una caja de texto un label, un boton y dejar los nombres:
textbox1, button1, label1

Cuando tenemos que meter codigo en el formualrio tenemos que recordar que representaba el button1, el texbox1 y se pierde tiempo en ver en el diseñador que representa dicho control

para los texbox por ejemplo:
txtNombreCliente es mucho mas representativo que textbox1
lo mismopara los botones:
btnAceptar es mucho mas representativo y claro que button1

Lo mismo curre cuando creamos objetos en variables, simpre acostumbrarse a buscar una forma estandar de crear los nombres y nuestreo codigo sera en cualquier lugar de la aplicacion mas entendible para nosotros y futuros desarrolladores de nuestras aplicaciones

por ejemplo para crear una varible de tipo formulario en visual vasic net

'defino una variable llamada objFrmClientes del tipo frmBrowseClientes
dim objFrmClientes as new frmBrowseClientes

para definir otro objeto del tipo formulario por ejemplo para proveedores seria:
dim objFrmPorveedores as new frmBrowseProveedor

asi cada vez que definamos objetos de un mismo tipo tienen una forma estandar de llamarlos