Mapear entidad como clase en arquitectura 3 capas

Question

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 ¿? 

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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

Answer 6

 "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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

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

Answer 15

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

Answer 16

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

Answer 17

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

Answer 18

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.