none
Mapear entidad como clase en arquitectura 3 capas

    Pregunta

  • Mi pregunta es sobre el trabajo en 3 capas, es una buena practica mapear toda una tabla como clase ( entidad ) (propiedades y metodos) ¿? ... en el caso que no .. me podrian orientar de como trabajar de una buena forma ¿? 
    martes, 14 de febrero de 2012 3:00

Respuestas

  • Hola Piiidro,

    No he entendido muy bien la pregunta, pero generalmente, cuando hablamos de una arquitectura tres capas, la capa de datos suele estar formada por un ORM. Esto es un sistema que convierte en objetos de .net, tu base de datos (tablas, procedimientos, etc). Algo así como mapear toda la base de datos a objetos de c#.

    Así que si usas algún ORM como "Entity Framework" o "nhibernate", puedes tener acceso a tus datos de una forma fácil :).

    Aquí tienes un tutorial de Microsoft de Entity Framework: 

    http://msdn.microsoft.com/es-es/library/bb399182.aspx

    Y si estás interesado en probar otras cosas, por ejemplo aquí tienes otro de nhibernate:
    http://darioquintana.com.ar/articles/tutorial-de-nhibernate-primeros-pasos

    martes, 14 de febrero de 2012 10:11
  • es una buena practica mapear toda una tabla como clase

    por lo general una entidad de tu modelo mepeara a una tabla como minimoqunque si estas modelando orientado a objetos y quieres implementar hereancia puede que una entidad mapee a mas d una tabla o que 2 o ams clases mapee a una sola tabla

    que tanto beneficio existe al trabajar con frameworks como entity, linq, etc .... es realmente conveniente hacerlo ¿

    en realidad depnde si puede usarlos o no, hay proyectos en dodne no puede hacerlo porque debes usar stored procedure, en estos casos un ORM no seria tan util, o perderias la ventajas principal que es el mapeo automatico

    si recomendaria veas estos videos

    Videos: Introducción al Entity Framework 4

    para aprender sobre EF y despues sacar tus propias conclusiones, si puede o no aplciarlo depende de ti, peor para poder tomar la desicion debes priemro aprender a usarlo

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    • Marcado como respuesta nazOut martes, 14 de febrero de 2012 13:28
    martes, 14 de febrero de 2012 11:59
  • Buen dia, agradesco a todos su interes por ayudarme, como les comente hace tiempo que deje de programar en NET (por cuestiones laborales tuve que usar VFP 9) .... la cuestion es que me he atrasado mucho (yo solo conocia LINQ a un nivel bajo/medio) ... pues ahora me intereso retomar las novedades del NET ....

    No se si es su caso pero la teoria si se entiende (la teoria siempre es lo mas sencillo de entender) ... el detalle viene en la practica y/o aplicacion (implementacion) ..... como por ejemplo ...

    1) Buenas practicas ¿ EF o crear mis propias clase ? [reutilizar codigo] - OK ... leere sobre EF hare un vs sobre cual me conviene mas. Relacion con punto (3)
    2) Mapeo total de la BD ¿en que layer ponerla?
    3) ¿ Al usar EF ya no tendre que crear una clase para conectar con mi BD ?


    using var conexion = (ConfigurationManager.conectionStrings["ADO.CON"].ConnectionString);{
     	//Bloque de codigo
    }

    Bueno son muchas cosas.
    Gracias a los que me ayudan a caminar con esto.
    Saludos

    Piiiidro, yo estuve trabajando con VFP hasta la versión 8 y la beta de la 9. Tengo que reconocer que era un gran lenguaje pero estaba demasiado cerca de la base de datos. En .NET tienes que intentar hacer un cambio de mentalidad, pero por suerte tienes herramientas como son los ORMs que te van a facilitar la vida.

    La ventaja principal de un ORM (como te dice Fernando) que te va a abstraer del uso a bajo nivel la base de datos. No es necesario crear conexiones, saber el nombre de las tablas o conocer las store procedures con las que vas a trabajar, de todo eso se va a encargar el ORM. Lo importante es que vas a trabajar con tus entidades de dominio (para que nos entendamos, tus clases) y será el ORM el que se ocupe de obtener y persistir los datos en la base de datos.

    Entity Framework es una buena herramienta, aunque hay otras igual de válidas como NHibernate. Lo importante es que encuentres una con la que trabajes a gusto. Más que links a otras discusiones de los foros, creo que te será más útil ir a la fuente: http://msdn.microsoft.com/es-es/library/bb399567.aspx y entiendas qué hace Entity Framework antes de intentar aplicarlo.

    martes, 14 de febrero de 2012 14:32

Todas las respuestas

  • Hola Piiidro,

    No he entendido muy bien la pregunta, pero generalmente, cuando hablamos de una arquitectura tres capas, la capa de datos suele estar formada por un ORM. Esto es un sistema que convierte en objetos de .net, tu base de datos (tablas, procedimientos, etc). Algo así como mapear toda la base de datos a objetos de c#.

    Así que si usas algún ORM como "Entity Framework" o "nhibernate", puedes tener acceso a tus datos de una forma fácil :).

    Aquí tienes un tutorial de Microsoft de Entity Framework: 

    http://msdn.microsoft.com/es-es/library/bb399182.aspx

    Y si estás interesado en probar otras cosas, por ejemplo aquí tienes otro de nhibernate:
    http://darioquintana.com.ar/articles/tutorial-de-nhibernate-primeros-pasos

    martes, 14 de febrero de 2012 10:11
  • Yo por lo general suelo generar mis propias clases y y crear metodos y propiedades, quisiera saber que tanto beneficio existe al trabajar con frameworks como entity, linq, etc .... es realmente conveniente hacerlo ¿? ..

    Muchas gracias.

    martes, 14 de febrero de 2012 11:18
  • Hola de nuevo,

    Mi opinión es que, por lo general, es mejor usar estas frameworks, ya que te proveen de un sistema ya probado, con un mantenimiento, en constante evolución (mejoras) y donde se aplican "best practices". Es decir, son herramientas muy sólidas, y en el caso de Entity Framework, con una compañía muy importante manteniendola ;).

    Y eso sin contar con que son de uso estandar y gracias a eso cualquier persona que se documente o las haya usado ya, puede hacerse rápidamente con un código fuente que les dé uso...

    Hay un principio que se repite pero no se suele documentar: no reinventes la rueda. Esto se refiere a que si ya está hecho y está bien hecho, ¿para qué volverlo a hacer?

    Por otro lado, también creo que existen excepciones a esto. Pero eso es en un 0.001% de las ocasiones...

    PD: Linq2Sql ya no está en uso, y por lo tanto no es recomendable usarlo. En su lugar Entity Framework sigue en constante evolución, con nuevas mejoras en cada versión.


    Fernanando Escolar - http://www.programandonet.com/ - @fernandoescolar

    martes, 14 de febrero de 2012 11:28
  • Hola Piiidro,

    La verdad es que tus dudas podrian ser explicadas bastante extensamente. En cualquier caso, revisa estos otros hilos que plantean dudas similares a las tuyas:

    http://social.msdn.microsoft.com/Forums/es/netfxwebes/thread/595c9403-e8ca-48e5-af40-b160d44bc4a5

    http://social.msdn.microsoft.com/Forums/es/netfxwebes/thread/7943eefc-911b-4165-a84c-de12c11d5247

    http://social.msdn.microsoft.com/Forums/es-ES/adodotnetentityframeworkes/thread/bb5f1a9d-98f7-4530-b42c-2d8d290d00db

    Saludos,

    JA Reyes.


    Please remember to Vote & "Mark As Answer" if this post is helpful to you.
    Por favor, recuerda Votar y "Marcar como respuesta" si la solución de esta pregunta te ha sido útil.

    martes, 14 de febrero de 2012 11:55
  • es una buena practica mapear toda una tabla como clase

    por lo general una entidad de tu modelo mepeara a una tabla como minimoqunque si estas modelando orientado a objetos y quieres implementar hereancia puede que una entidad mapee a mas d una tabla o que 2 o ams clases mapee a una sola tabla

    que tanto beneficio existe al trabajar con frameworks como entity, linq, etc .... es realmente conveniente hacerlo ¿

    en realidad depnde si puede usarlos o no, hay proyectos en dodne no puede hacerlo porque debes usar stored procedure, en estos casos un ORM no seria tan util, o perderias la ventajas principal que es el mapeo automatico

    si recomendaria veas estos videos

    Videos: Introducción al Entity Framework 4

    para aprender sobre EF y despues sacar tus propias conclusiones, si puede o no aplciarlo depende de ti, peor para poder tomar la desicion debes priemro aprender a usarlo

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    • Marcado como respuesta nazOut martes, 14 de febrero de 2012 13:28
    martes, 14 de febrero de 2012 11:59
  •  "hay proyectos en dodne no puede hacerlo porque debes usar stored procedure, en estos casos un ORM no seria tan util,"

    Leandro Tuttini

    Hola Leandro,

    No he entendido muy bien esta parte, ¿me podrías explicar qué problemas puedo encontrar usando stored procedures con un ORM como Entity Framework? Gracias! :)


    Fernanando Escolar - http://www.programandonet.com/ - @fernandoescolar

    martes, 14 de febrero de 2012 12:02
  • problema no, pero pierdes la esencia del ORM que es justamente la de generar el mapeo por ti

    digo si pierdes lo principal de un framework despues que lo hagas con un ORM o no es indistinto


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    martes, 14 de febrero de 2012 12:05
  • Hola Leandro,

    Sigo sin entender del todo a lo que te refieres. Lo digo porque acabo de realizar una prueba y EF me ha mapeado un stored procedure que me devolvía varios registros especiales y me ha creado un objeto result (ya que no son registros "limpios" de una tabla ni vista), para recoger esa llamada...

    La verdad que me ha parecido favuloso para usarlo en mi capa de persistencia. Pero no obstante si no es una buena practica o hay mejores herramietas o formas, prefiero en mis futuros desarrollos usarla... 

    ¿Me podrías proponer algo alternativo?

    Muchas gracias de antemano!


    Fernanando Escolar - http://www.programandonet.com/ - @fernandoescolar

    martes, 14 de febrero de 2012 12:10
  • no dije que no se pueda hacer

    pero no lo veo como un unico camino, EF esta bien pero no siemrpe podras aplicarlo

    esta bien que te guste, pero apunto a que no hay que ir como sigo solo a una tecnologia, si vas a usar procesures puedes usar un orm o no porque la esencia de mapeo y creacion de entidades basadas en la persistencia ya no es tan directa ni flexible

    apunto a que debes evaluar las situaciones, por eso no le di uan repsuesta Piidro, sino que dejo que aprenda EF y vea si le es util o no para el esquema que plantrea

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    martes, 14 de febrero de 2012 12:20
  • no dije que no se pueda hacer

    Sí, lo has dicho, te cito: "en realidad depnde si puede usarlos o no, hay proyectos en dodne no puede hacerlo porque debes usar stored procedure".

    Me parece que estás haciendo un flaco favor contestando una cosa y seguidamente la contraria.

    martes, 14 de febrero de 2012 12:40
  • a donde apuntaba con ese comentario es que lo general es aprovechar una tecnologia

    ORM apunta a mapear automaticamente las entidades a las tablas, si todo el acceso esta condicionado a usar stored procedure  se pierde el sentido de esa ventaja de mapeo

    por eso si usas procedure puede no ser conveniente usar EF, si tienes todo el modelo basado en ORM y algun que otro procedure para algun caso particular de performance si se podria suar EF, pero si todo el acceso es por medio de procedure, que sentido tiene, si se pierde la ventaja

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    martes, 14 de febrero de 2012 12:50
  • Hola Piiidro,

    La verdad es que tus dudas podrian ser explicadas bastante extensamente. En cualquier caso, revisa estos otros hilos que plantean dudas similares a las tuyas:

    http://social.msdn.microsoft.com/Forums/es/netfxwebes/thread/595c9403-e8ca-48e5-af40-b160d44bc4a5

    http://social.msdn.microsoft.com/Forums/es/netfxwebes/thread/7943eefc-911b-4165-a84c-de12c11d5247

    http://social.msdn.microsoft.com/Forums/es-ES/adodotnetentityframeworkes/thread/bb5f1a9d-98f7-4530-b42c-2d8d290d00db

    Saludos,

    JA Reyes.


    Please remember to Vote & "Mark As Answer" if this post is helpful to you.
    Por favor, recuerda Votar y "Marcar como respuesta" si la solución de esta pregunta te ha sido útil.


    Hombre, pero alguna explicación sí que podrías dar, ¿no? Entiendo que es más fácil contestar con 3 links que desarrollar una respuesta, pero con una línea o dos creo que Piiidro (y todos los que lean este foro) lo tendrían más claro.
    martes, 14 de febrero de 2012 12:51
  • a donde apuntaba con ese comentario es que lo general es aprovechar una tecnologia

    ORM apunta a mapear automaticamente las entidades a las tablas, si todo el acceso esta condicionado a usar stored procedure  se pierde el sentido de esa ventaja de mapeo

    por eso si usas procedure puede no ser conveniente usar EF, si tienes todo el modelo basado en ORM y algun que otro procedure para algun caso particular de performance si se podria suar EF, pero si todo el acceso es por medio de procedure, que sentido tiene, si se pierde la ventaja

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    Ahora has razonado la respuesta, en las 3 anteriores has escrito lo primero que se te ocurrió. Creo que Piiidro y cualquiera que escriba en los foros se merecen un poco de consideración en cuanto a las respuestas recibidas.

    martes, 14 de febrero de 2012 12:55
  • yo me pregunto, porque no puede contestar con 3 links?

    cada uno es libre de participar como quiera sin que se lo cuestione como lo hace y lo que recomieda

    algunos tienen ganas de escribir mas que otros, pero no por eso la respuesta es incorrecta, hay miles de preguntas que se repiten a diario

    hacer referencia a estas hace que la proxima vez quien consulta realice primero una busqueda en preguntas realizadas para ver si alguna se responde sus dudas

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    martes, 14 de febrero de 2012 12:58
  • Buen dia, agradesco a todos su interes por ayudarme, como les comente hace tiempo que deje de programar en NET (por cuestiones laborales tuve que usar VFP 9) .... la cuestion es que me he atrasado mucho (yo solo conocia LINQ a un nivel bajo/medio) ... pues ahora me intereso retomar las novedades del NET ....

    No se si es su caso pero la teoria si se entiende (la teoria siempre es lo mas sencillo de entender) ... el detalle viene en la practica y/o aplicacion (implementacion) ..... como por ejemplo ...

    1) Buenas practicas ¿ EF o crear mis propias clase ? [reutilizar codigo] - OK ... leere sobre EF hare un vs sobre cual me conviene mas. Relacion con punto (3)
    2) Mapeo total de la BD ¿en que layer ponerla?
    3) ¿ Al usar EF ya no tendre que crear una clase para conectar con mi BD ?


    using var conexion = (ConfigurationManager.conectionStrings["ADO.CON"].ConnectionString);

    { //Bloque de codigo }


    Bueno son muchas cosas.
    Gracias a los que me ayudan a caminar con esto.
    Saludos

    martes, 14 de febrero de 2012 13:21
  • En contestación a tus preguntas:

    1) Generalmente usar un ORM como EF, pero evidentemente depende del escenario total.

    2) Como contesté en el primer post, si estas en el modelo de tres capas, la respuesta es: en la capa de datos.

    3) No la necesitarás, EF es una herramienta que te abstrae de las conexiones con las bases de datos. Esa es una de sus virtudes.


    Fernanando Escolar - http://www.programandonet.com/ - @fernandoescolar

    • Propuesto como respuesta pbousan martes, 14 de febrero de 2012 14:03
    martes, 14 de febrero de 2012 13:26
  • 1-

    solo tu puedes tomar esa decision dependiendo de como armas el desarrollo, evalua ambos caminos, realiza pruebas usando EF y ver como te sientes usandolo, puede que te guste como puede que no

    2-

    por supuesto en la capa de acceso a datos

    [N-Tier] – Desarrollo en capas - Ejemplo Facturacion - parte 3

    3-

    el framework lo hace por ti, pero ojo porque igual hay clase de configuracion (mas si usas Code First) y modelos de diagramas, o sea magia no existe, sino que unas cosas son reemplazadas por otras

    recomendaria que veas el tema de Code First para el mapeo si es que te gusta EF, lo veo mas robusto que usar los diagramas visuales

    Desarrollando con código primero en Entity Framework 4

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina


    martes, 14 de febrero de 2012 13:32
  • Buen dia, agradesco a todos su interes por ayudarme, como les comente hace tiempo que deje de programar en NET (por cuestiones laborales tuve que usar VFP 9) .... la cuestion es que me he atrasado mucho (yo solo conocia LINQ a un nivel bajo/medio) ... pues ahora me intereso retomar las novedades del NET ....

    No se si es su caso pero la teoria si se entiende (la teoria siempre es lo mas sencillo de entender) ... el detalle viene en la practica y/o aplicacion (implementacion) ..... como por ejemplo ...

    1) Buenas practicas ¿ EF o crear mis propias clase ? [reutilizar codigo] - OK ... leere sobre EF hare un vs sobre cual me conviene mas. Relacion con punto (3)
    2) Mapeo total de la BD ¿en que layer ponerla?
    3) ¿ Al usar EF ya no tendre que crear una clase para conectar con mi BD ?


    using var conexion = (ConfigurationManager.conectionStrings["ADO.CON"].ConnectionString);{
     	//Bloque de codigo
    }

    Bueno son muchas cosas.
    Gracias a los que me ayudan a caminar con esto.
    Saludos

    Piiiidro, yo estuve trabajando con VFP hasta la versión 8 y la beta de la 9. Tengo que reconocer que era un gran lenguaje pero estaba demasiado cerca de la base de datos. En .NET tienes que intentar hacer un cambio de mentalidad, pero por suerte tienes herramientas como son los ORMs que te van a facilitar la vida.

    La ventaja principal de un ORM (como te dice Fernando) que te va a abstraer del uso a bajo nivel la base de datos. No es necesario crear conexiones, saber el nombre de las tablas o conocer las store procedures con las que vas a trabajar, de todo eso se va a encargar el ORM. Lo importante es que vas a trabajar con tus entidades de dominio (para que nos entendamos, tus clases) y será el ORM el que se ocupe de obtener y persistir los datos en la base de datos.

    Entity Framework es una buena herramienta, aunque hay otras igual de válidas como NHibernate. Lo importante es que encuentres una con la que trabajes a gusto. Más que links a otras discusiones de los foros, creo que te será más útil ir a la fuente: http://msdn.microsoft.com/es-es/library/bb399567.aspx y entiendas qué hace Entity Framework antes de intentar aplicarlo.

    martes, 14 de febrero de 2012 14:32