Tipos Genericos

[mamcx]

Empezado por elrayo76

Lo que quisiera es que me orienten en como armar ese mini framework que quiero. También si saben de donde se puede sacar algún códio fuene de un mini-ORM para estudiarlo se los agradecería.

Dapper, el que puse, es el mas "famoso" de esa categoria, al menos en lo que he visto. Si buscar en google veras muchos mas.

P,D: Me acorde que escribi sobre eso hace años:

http://edn.embarcadero.com/article/32388
http://blog.elmalabarista.com/post/4...h-un-mejor-rad

Que pueden verse como un micro-ORM, en pocas lineas de delphi

hacer un especie de framework para la conexión con la base de datos para luego poder cambiarlo si es que cambia el motor de base de datos.

Un punto para ambos: Programar para el caso incierto, futuro de *si es que a lo mejor quien sabe, yo realmente se es X pero y que pasa si la luna se pone roja y toca usar Y???* es una de las formas mas *populares* entre nosotros los programadores de perder el tiempo.

Que tan igual es Firebird a Sql Server? Superficialmente, mucho, pero en la *practica*? A parte de los mas elementales SELECTs no hay mucho que se pueda compartir entre motores, Asi que piensen: Que es mas productivo, practico y realista: Hacer decenas de clases que intenten abstraer (aun mas de lo que el estandar SQL mas elemental + librerias de acceso a datos *ya hacen*) y todo el esfuerzo que eso implica VS hacer asi:

Código Delphi [-]

if Engine='sqlServer' then
   return 'SELECT sqlServer'
.....
.....

Chequen estas librerias:

https://github.com/krisajenkins/yesql
https://bitbucket.org/rick/jasql

El truco que tienen, muy obvio (y que en mis articulos apunte de una forma menos practica!) es que puedes convertir el SQL en "constantes". Usando jasql, uno tiene un archivo asi:

Código SQL [-]
-- name: create-user
INSERT INTO users (name, email) VALUES(@name, @email)

-- name: find-one-user-by-email
SELECT id,name,email FROM users WHERE email = @email LIMIT 1

"name: create-user" es un llave al sql, que desde el codigo se invoca asi:

Código PHP:

var jaSql = JaSql.FromFile("queries.sql");
using (var cn = new SQLiteConnection("<your connection string here>"))
using (var jaRunner = jaSql.CreateRunner(cn))
{
  jaRunner.Execute("create-users-table");

  jaRunner.Execute("create-user", new {name = "John Doe", email = "[email protected]"});
  var user = jaRunner.Query<User>("find-one-user-by-email", new {Email = "[email protected]"}).First();
} 


Las clases Tfield y TDomain, me sirven de apoyo para configurar tanto del lado del cliente como del servidor las especificaciones de cada campo, como su longitud, tipo, valores permitidos, etc. Esto me es muy útil para el ingreso y validación de los datos que suministra el usuario.

Ok, ya veo que lo que buscan tiene que ver con ORM, pero es mas acerca de como soportar el escenario de dejar configurable la app/tablas/formularios/etc.

Ahora es popular usar JSON en blob de una tabla para guardar arboles de objetos/configuraciones, pero antes que los hipsters entraran en escena uno simplemente usaba tablas con campos y ya. Por ejemplo, digamos que uno tiene:

Código PHP:

FormLogin =
  user = Num , check notEmpty
  pwd = Num , check notEmpty
check user = pwd 


Pues uno puede aceptar que eso exactamente, puede hacerlo la BD y generar el sql que construye esa tabla con esos checks. Si el formulario cambia, pues se hace DROP a la tabla y se recrea. Es ideal tener una BD de usuario dinamico separada de la estatica del sistema, que es muy facil en la mayoria de los motores, o usar SQLITE que se invento especificamente para esto: Para ser un excelente sistema de creacion de formatos de archivos personalizados (que reemplace .INI, .XML, etc)

Usando introspeccion se puede extraer mucho de una BD. Si el asunto se pone complejo es porque realmente se esta intentando re-crear un sistema de datos personalizado, y eso si que es complejo.

FoxPro efectivamente guardaba proyectos, formularios, reportes, tablas y base datos en tablas .dbf. Eso significaba que uno podia abrir un formulario y hacer el insert con un nuevo campo si se respetaba las reglas de como debe ser la informacion.

Pero eso tambien signfica que mientras mas personalizado quieras que el usuario haga sus formularios, informes, menus, etc mas cerca estas de re-inventar foxpro o acces.

Si ese es su objetivo, les digo que estoy haciendo eso, creando ese tipo de herramienta, y no me chocaria tener mas brazos El punto es que lo estoy haciendo en .NET + F#