[SOURCE]MB-CONTAv1.0

[E N T E R]

Esta semana estaba mas libre que no se que cosa y me puse a probar el vb.NET y salio este: Un programita para mi ciber que me sirve para controlar los ingresos, gastos y créditos de mis clientes. La base de datos esta con MySQL en el source esta todo el script de la bd.

[SOURCE DEL PROGRAMA]
http://www.mediafire.com/?f418o19gl72i1ex

SCRENN DEL PROGRAMA

[raul338]

Esta lindo y parece fluido! Despues veré el codigo

[seba123neo]

esta bastante bien, salvo alguna cosas que veo que habria que corregir.

1 - esto algunos lo toman como una estupidez, pero no lo es, la nomenclatura de los controles, formulario o cualquier objeto, variables,etc...eso es importante hacerlo bien sino cualquiera que ve el proyecto ni le da ganas de verlo con esos nombres, por ejempo Form1, Form2, Form3, no se sabe que hace cada uno. yo te lo digo porque cuando comenze hacia lo mismo, y despues me di cuenta lo util que es saber que hace cada objeto y que te quede todo ordenado los nombres, lo mismo para las variables globales, locales, parametros de funcion, etc.

2 - no se porque usas la referecia de la dll de mysql ya que se puede conectar a mysql usando el oledb de .NET

3 - no se si es lo mejor conectar y desconectarse de la base al hacer cualquier consulta, veo que te conectas y desconectas en cada operacion, el modo desconectado tendria sentido si trabajaras con datasets, pero como es hacer simples consultas y llenar grillas, el modo conectado no tiene problema.

4 - siempre recomiendo comenzar desde el sub main del modulo para conectar a la base, antes de que se cargue cualquier formulario.

5 - a la logica de cada entidad (articulo, cliente, lo que sea) la podes programar en capas o clases separadas, ya que sino estaria programado muy a la VB6 y no aprovechas lo que te brinda .NET, yo una ves que me acostumbre a programar en capas no lo deje mas, aparte te queda limpio el codigo del formulario, ya que todas las consultas y operaciones con la base se programarian dentro de las clases.

saludos.

[cristian_19a]

Bien Enter
aver Seba tu que eres moderador de NET de este foro
subete un proyecto tuyo con N-CAPAS, para ver como trabajan eso de clases, entidades, listas, encapsulamiento
hasta ahora no he visto un proyecto tuyo.

[pedroesca]

ESPECTACULAR querido Enter!!

[seba123neo]

Bien Enter
aver Seba tu que eres moderador de NET de este foro
subete un proyecto tuyo con N-CAPAS, para ver como trabajan eso de clases, entidades, listas, encapsulamiento
hasta ahora no he visto un proyecto tuyo.

no quiero creer que esto es un reto a mi saber o algo por el estilo.

[E N T E R]

Gracias a todos por responder. y en especial a Seba que ya me ayudo muchísimo y a todos y en mucho foros aprecio mucho eso , pero me pico este la podes programar en capas o clases separadas, ya que sino estaria programado muy a la VB6 y no aprovechas lo que te brinda .NET pero yo se que no es por maldad ni nada ni lo tome a mal encerio yo se que el amigo seba no es así es solo por ayudar y hacer entender.

Pero la verdad me gustaría Seba que pusieras algún ejemplo de como programar en capas me interesa mucho eso. y sobre el proyecto es solo una prueba a ver si podía hacer algo con el .net me salio todo lo que quería no es una gran cosa como primer proyecto camina bastante bien. y esperando por esto: http://leandroascierto.com/foro/index.php?topic=1633.0

Saludos...

[cristian_19a]

reto para nada solo que tus criticas algunas son ciertas y algunas no
y por eso quiero ver como trabajas tu en tus proyecto nada mas.

[seba123neo]

reto para nada solo que tus criticas algunas son ciertas y algunas no
y por eso quiero ver como trabajas tu en tus proyecto nada mas.

me gustaria saber cuales no son ciertas.

[ssccaann43]

Tomando en cuenta lo que dice Seba..

Su punto 1
(1 - esto algunos lo toman como una estupidez, pero no lo es, la nomenclatura de los controles, formulario o cualquier objeto, variables,etc...eso es importante hacerlo bien sino cualquiera que ve el proyecto ni le da ganas de verlo con esos nombres, por ejempo Form1, Form2, Form3, no se sabe que hace cada uno. yo te lo digo porque cuando comenze hacia lo mismo, y despues me di cuenta lo util que es saber que hace cada objeto y que te quede todo ordenado los nombres, lo mismo para las variables globales, locales, parametros de funcion, etc.)

Ciertamente así es, puesto que lo más dificil en la programación es entender un codigo ajeno y aun más cuando este no está ordenado....

Punto 2
(2 - no se porque usas la referecia de la dll de mysql ya que se puede conectar a mysql usando el oledb de .NET)

En .NET se facilita la conexión a MySQL, totalmente deacuerdo con sebaneo...

Punto 3.
(3 - no se si es lo mejor conectar y desconectarse de la base al hacer cualquier consulta, veo que te conectas y desconectas en cada operacion, el modo desconectado tendria sentido si trabajaras con datasets, pero como es hacer simples consultas y llenar grillas, el modo conectado no tiene problema.)

Lo más factible es que apertures la conexion y la cierres cuando finalices el sistema, total es un aplicativo pequeño y no trabajas con datasets. Es mucho más facil lanzar las consultas, abrir y cerrar los recordsets y ya, sin tener que aperturar y cerrar conexion a cada momento... Pues imaginate que realizaras consultas simultaneas, por cada una aperturas la conex y la cerraras??? Mejor es tenerla aperturada...

Punto 4
(4 - siempre recomiendo comenzar desde el sub main del modulo para conectar a la base, antes de que se cargue cualquier formulario.)

Es lo más sensato puesto que alertarias al usuario de manera idonea si el sistema puede o no conectarse a la base de datos y no le causas la confusion de que el sistema cargo pero ahora no se conecta... Por poner un ejemplo... Lo correcto es habilitar y aperturar la conexion en un Main y luego cargar el formulario...

Punto 5
(5 - a la logica de cada entidad (articulo, cliente, lo que sea) la podes programar en capas o clases separadas, ya que sino estaria programado muy a la VB6 y no aprovechas lo que te brinda .NET, yo una ves que me acostumbre a programar en capas no lo deje mas, aparte te queda limpio el codigo del formulario, ya que todas las consultas y operaciones con la base se programarian dentro de las clases.)

Aqui tienen el ejemplo en desarrollo por capas http://ltuttini.blogspot.com/2010/06/n-tier-desarrollo-en-capas-ejemplo.html

Ahora bien...

reto para nada solo que tus criticas algunas son ciertas y algunas no
y por eso quiero ver como trabajas tu en tus proyecto nada mas.

Cuales cosas no son ciertas??? Ya que afirmas con seguridad que "Algunas no lo son" ??

No quiero causar problemas o incomodar, pero si criticamos lo hacemos para Construir, no para destruir...!

Saludos y estoy a la orden, por si quieren ponerme a prueba...!

[E N T E R]

Yo en este proyecto tengo así los nombres de los formularios nada mas por que es el primer programa que hice con .net y todo es a prueba y error.

Ahora lo de conectar y cerrar lo hago por que la verdad no me queda claro como dejar abierto la y volver a utilizar sin cerrar, siempre me da el error que esta abierto otro lado.

Para mi todas la criticas son constructivas yo se que todo lo que se diga acá en este foro es para bien y nunca dudaría de todo ustedes por que mucho ya he aprendido gracias a ustedes.

[YAcosta]

Hola Enter, te da error porque tienes abierto el RecordSet, no por la conexión.

Si tienes el recordset declarada a nivel de modulo normal, puedes hacerlo pero antes de cada consulta deberas poner

if rs.state then rs.close
rs.Open TuSQL, dB, 1, 1    '<--- esta seria tu nueva consulta y siempre irá bien porque llega ya cerrada la consulta previa que halla habido

Sino declaras el recordset en cada punto donde lo uses.

Para grabar no necesitarías nunca el rs porque usas el Execute.

Redondeando la idea:
En las declaraciones de tu proyecto declaras:
Public dB As ADODB.Connection

En otro Modulo haces la conexión usando ese conector (en mi caso dB, osea dB.Open TuConexion)

Declarando en cada necesidad:
En lo personal no declaro el rs a nivel de módulo, lo declaro cada vez que lo necesite para no tenerlo en memoria todo el tiempo mas aun que trabajo en red y la gente hace actualizaciones: "lo necesito, lo uso". En muy contados casos si declaro un rs a nivel global pero casi nunca lo hago.

Y listo. Cuando estas en un formulario X y quieres leer algo pondras:
(Asumiendo que lo prefieras declarar por cada necesidad, sino recuerda que usarias if rs.state then rs.close)
Dim rs As New ADODB.Recordset
rs.Open TuSQL, dB, 1, 1

Usas normal el rs asi lo hallas usado en otra parte porque su alcance es solo en ese evento, función o procedimiento ya que alli lo estas declarando y como ya tiene el conector (db que es Global) siempre va bien y vivira hasta que muera la aplicacion o ser pierda la conexión de red*.

Y cuando quieras grabar, borrar o actualizar no declaras nada, mandas la orden sin mas:
db.BeginTrans      <--- Recomendable
dB.Execute TuSQL, , adCmdText
db.CommitTrans

Y listo, nunca te dará el problema que indicas. Obviamente toda esta explicación es para VB6 porque desde allí sé que lo manejas asi, para .Net ya nos indicaran como seria pero puedo sospechar que la lógica es la misma.

Saludos


* Si el tema es para internet, o sea que la BD este en la nube entonces si, tengo entendido que tu método seria el adecuado, pero sabemos que no estamos en eso (al menos no de manera comercial y menos con VB6) y hacemos conexión sobre area local (a veces ni eso).
Vengo usando esta forma por varios años y en varias implementaciones en red y NUNCA tuve problemas que comentar. Haciendo memoria quiza una que otra vez la red se cayo por cuestiones de Hardware (cosa rara) y lo único que debía hacer el personal era cerrar y volver a abrir el programa, como uso el BeginTrans/CommitTrans no hay transacciones incompletas que lamentar (de esas que grabas una vez y mueves varias tablas). Tu me diras: Yo tampoco!!! y yo te dire ¿a que costo?, no se que tan malo o no sea estarse desconectando y reconectando con el motor reiteradas veces por cada pestañeada, pero lo que si es cierto es que me ahorro código (así lo tengan en procedimiento) y ya por ese hecho me resulta beneficioso.

[raul338]

Con todos los demás puntos estoy totalmente de acuerdo. Sobre la programación en capas, es como el mismo principio que la POO, si quieres agregar /cambiar algo, no tienes que reprogramar todo. Imagina que quieres hacer un sistema que sea por PC(s) y a la vez que el "jefe" pueda ver las estadisticas por su celular (interenet), solo tienes que programar todo el acceso a la BD en una DLL y de ahí dividir en 2 proyectos, uno por formulario para los que atienden, y otro web/webservice para "el jefe" y así si tambien es para compra online, hacer versionado, etc...

Punto 2
(2 - no se porque usas la referecia de la dll de mysql ya que se puede conectar a mysql usando el oledb de .NET)

En .NET se facilita la conexión a MySQL, totalmente deacuerdo con sebaneo...

Pero, no se necesita siempre una dll en ambos casos? Usando el conector "nativo" para .net, necesitas la DLL, si usas OleDb puro, necesitas el conector OleDB de MySQL, así que estamos en la mismas en los 2

[cristian_19a]

jajajaja creo que este foro la primera vez que yo ingrese son por los controles creados por Leandro, Cobein y Raul.
Me parecierón interesante revisarlo y aprender de ellos y se los agradesco.

se que las criticas son constructivas pero siempre hay que criticar con sabiduria ala persona segun su grado o conocimiento de algo.

Conosco a ENTER se que es una persona que aprendio por decir impiricamente el vb6
ya que solo programa en modo mono, ya que no trabaja en 3 capas en el mismo vb6

y para hacer esa aplicacion en net lo veo que va por un buen camino
se que le falta en cuestion de programacion para lograr una buena optimizacion de recursos en cuestion de cliente-servidor
por lado del cliente solo trabaja con simples consultas y por lado del servidorSQL no logra hacer trabajar al 100% al servidor
ya que todo lo recarga en el aplicativo

Pero hasta ahora no se quien me dio mi -1 Jajaja
Bueno ese link que envia ssccaann43 dice programar en capas, yo no veo nada de programacion en 3 capas
yo solamente veo simples consultas SQL con variables temporales no veo uso de entidades, encapsulamiento de listas, no veo nada de clases para la conexion, Customer, Invoice. No veo nada de modelo - vista -Controlador, no veo ni lo basico de 3 capas presentacion-negocio-datos.
Creo que en youtube hay video basicos de desarrollo solo en 3 capas con NET

y eso de DataSet es para trabajar en modo nativo para eso existen las listas encapsuladas en la programacion en capas
y criticas que trabaje con la conexion abierta siempre que ejecute el aplicativo y cuando cierre el aplicativo cierre la conexion
bueno eso tiene varias desventajas tanto para el aplicativo y para el servidor.

he visto que Raul tiene mas acertes en eso de proveedor para conectar la aplicacion con MYSQL
los creadores del controlador net para mysql no son locos de crear el controlador dll para conectarse ala base de datos.
No se puede comparar el OLEDB de NET con el proveedor del mismo MYSQl ya que tiene mas ventajas y funciones para manejar y administrar la base de datos

Claro Raul de eso se trata la Programacion en N Capas
Si tu tienes tu dll de conexion, clientes, proveedores yo que se, lo puede usar en diferentes aplicativos ya sea de escritorio o web
lo puedes manejar a tu antojo en ASP, puedes dar un WEBSERVICE y es mas puedes hacer uso de PHP, java para usar el WEBSERVICE
sin tener que programar mucho ya que todo esta en DLL's

Estoy agradecido con Leandro, Cobein, Raul
y con Ivan quien dio a conocer el FirebirdSql ya que antes yo solo estaba amarrado con Oracle y SqlServer y no conocia otras servidores SQL y ahora conosco mas de 6 ServidorSQL

Gracias a todos

[seba123neo]

Pero, no se necesita siempre una dll en ambos casos? Usando el conector "nativo" para .net, necesitas la DLL, si usas OleDb puro, necesitas el conector OleDB de MySQL, así que estamos en la mismas en los 2

perdon, me confundi  , no es con oledb, es con odbc, o sea con el espacio de nombres System.Data.Odbc, con ese te podes conectar tranquilo a MySQL (usando en la cadena de conexion el driver de MySQL directamente o sea "DRIVER={MySQL ODBC 3.51 Driver};..etc.", o sea no hay que crear ningun DSN o ODBC como quieran llamarlo).

si necesitas solo hacer funciones basicas de SQL estandar, o sea SELECT, INSERT, DELETE, UPDATE o cualquier funcion del SQL estandar el Odbc te funciona bien, ahora si necesitas hacer cosas especificas o instrucciones que son propias de MySQL,  ahi si necesitas el .NET Connector, sino esas instrucciones no son reconocidas por el oledb.

si no he puesto algun ejemplo es por falta de tiempo y trabajo, pero les aseguro que esta semana  lo pongo, si no cumplo le doy permiso que me borre Leandro como usuario del foro. tambien quiero comenzar a poner cosas de android que para eso le hice crear el subforo, he aprendido tanto de este tema, que estoy haciendo un curso de java/android en la empresa y el profesor me dijo que de la clase yo jaja.

saludos.