none
NHibernate vs EF (Help Leandro Tuttini y demás) RRS feed

  • Pregunta

  • Saludos

     

    Ayudenme con esta duda que tengo que es mejor para mi software de Cooperativa de Ahorro y Credito que estoy haciendo


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    lunes, 18 de julio de 2011 16:30

Todas las respuestas

  • ¿A quien amas más, al padre o a la madre?

    Para gustos los colores... Por norma general, pero cada uno tendrá su opinión al respecto y será tan respetable como cualquier otra, se considera que NHibernate es un ORM que está más maduro que EF (incluyendo EF4.1). NHibernate soporta cosas que EF todavía no soporta directamente (como p.ej. varios algoritmos para generar claves de entidades, soporte para enums, soporte para operaciones bulk, ...). Por su lado la mayor baza de EF es el soporte de MS y el tooling integrado en VS. Por otro lado, ahora que han separado EF del framework, se prevé que EF pueda tener actualizaciones más a menudo (sin tener que esperar a una nueeeeeeeeeeeva versión de VS o del fwk de .NET).

    Así que... que es lo mejor para tu software? Pues no sé: lo que te recomiendo es que estudies ambos y decidas tu mismo. Lo que sí puedo decirte, es que en mi opinión, la curva de aprendizaje de NHibernate es más alta, no tanto porque NHibernate sea intrínsicamente más dificil que EF, sino simplemente por la cantidad de informción disponible y el soporte de tooling por parte de VS.

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    • Propuesto como respuesta Nicoloco martes, 19 de julio de 2011 22:03
    lunes, 18 de julio de 2011 19:01
  • Eso lo tengo claro... No sabia que EF había sido separado de Framework, lo que mas me limita de EF es la interoperabilidad con otros providers de datos open como MySQL, PostgreSQL que es un Motor muy potente tanto como Oracle y eso lo he visto en NH...

    Mi Aplicacion la estoy tengo divido en DAL, DLL, EL, GUI por eso quiero saber si esta sustentada su aplicación en sistemas de gestión escalables como facturacion masiva etc...


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    lunes, 18 de julio de 2011 19:31
  • Buenas!

    Sobre el papel, EF es agnóstico en cuanto a la BBDD. P.ej. según he leído el último connector de MySql para .NET (http://www.mysql.com/downloads/connector/net) tiene soporte para EF, con lo cual se puede usar en MySql. Lo que no sé es que soporta y que no.

    Y según he visto también parece que EF pueda usarse con PostgreSql: http://npgsql.com/index.php/2009/08/how-to-set-up-entity-framework-npgsql-part-1/

    Saludos!

     


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    martes, 19 de julio de 2011 6:21
  • MMM con esto entonces me dices que EF es mejor que NH???
    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    martes, 19 de julio de 2011 15:29
  • Hola, puess caray esto es como preguntar si java es mejor que C# (siendo c# mejor jaja :P) se arma un debate... puess en lo personal me gusta mas EF porque? porque es un producto Microsoft que viene pegado con tu VS 2010, ahi mayor soporte y en esta version 4.1 se vfe muy maduro.

    Saludos  


    Nicolás Herrera
    Bogotá - Colombia
    BLOG - Leader Group BogotaDotNet
    "Daría todo lo que sé, por la mitad de lo que ignoro." Rene Descartes
    martes, 19 de julio de 2011 22:07
  • Listo y como harías con que una aplicacion sea multimotor DB con EF?
    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    martes, 19 de julio de 2011 22:35
  • Teóricamente (y recalco lo de teóricamente) no debería preocuparte mucho el motor de BBDD que tengas en tu aplicación. Tu desarrollas contra tu modelo de entidades, y hay un mapping que mapea dichas entidades a las tablas "reales" de tu BBDD. Modificando este mapping puedes modifcar la estrucutra de la BBDD sin afectar a tu programa. Y modificando la cadena de conexión que usas EF se puede conectar a Oracle, SQL Server o lo que sea que tenga soporte para EF. Y tu programa de nuevo no lo nota ya que está desarrollado contra el modelo de entidades.

    Por supuesto, desarrollar un aplicación multi-bd implica algunas restricciones: nada de mandar SQL "directo" sin pasar por el modelo de entidades p.ej. Además de que los distintos proveedores de EF pueden tener cosas no-implementadas.

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    miércoles, 20 de julio de 2011 6:22
  • Lo se y tienes razon pero el alcance de mi proyecto es que sea multiDB.

    Al momento del login he creado una opcion oculta donde se elige el proveedores de datos informacion del servidor esto me serviria poder cambiar rapidamente la configuracion etc.

    https://skydrive.live.com/?cid=bb4fa4ec5f804415&sc=photos#!/?cid=bb4fa4ec5f804415&sc=photos&nl=1&uc=1&id=BB4FA4EC5F804415%211183!cid=BB4FA4EC5F804415&id=BB4FA4EC5F804415%211183&sc=photos 


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    jueves, 21 de julio de 2011 17:06
  • Hola

    mm no se que tan bueno es dejarle al usuario final escojer la BD contrala que quiere trabajar, te tocaria tener replicacion de datos y aplicar varias tecnicas de ese tipo.

    Yo de ti, apuntaria a lo recomendado por edward.. .

    Saludos


    Nicolás Herrera
    Bogotá - Colombia
    BLOG - Leader Group BogotaDotNet
    "Daría todo lo que sé, por la mitad de lo que ignoro." Rene Descartes
    viernes, 22 de julio de 2011 18:58
  • Bueno Nico,

    No lo dejarìa visible para el usuario final solo que en caso de una caida del server de Produccion tener una pantalla de configuracion para poder apuntar al nuevo server(replicacion)

     

    Por eso quiero saber cual es mejor o cual me aporta mas al enfoque que quiero aplicar cual me ayudaría mas en una aplicación en mi Capa de Datos y Mi Logica del Negocio


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    viernes, 22 de julio de 2011 19:10
  • Hola

    Pues te recomiendo EF, porque ya he hecho la practica con una BD en SQL Server y otra en MySQL ... la ventaja de trabajar con este ORM es que trabajas contra un modelo conceptual, es decir... a tu aplicacion no le importa CONTRA QUE ESQUEMA FISICO este trabajndo, siempre y cuando respetes la cadena de conexioon que te genera al crear el .edmx y las entidades y sus propiedades mantengan esta integridad.

    Lo dificil de este proceso sera el manejo de la replicacion, dado que si vas a manejar motores distintos, caray se complica.

    Te recomiendo evalues muy bien este requerimiento, dado que dara una complejidad añadida (y un tanto inutil desde mi punto de vista).

    NOTA: EF Rules jaja :P

    Atento a tu respuesta y demas comentarios

    Saludos.


    Nicolás Herrera
    Bogotá - Colombia
    BLOG - Leader Group BogotaDotNet
    "Daría todo lo que sé, por la mitad de lo que ignoro." Rene Descartes
    domingo, 24 de julio de 2011 22:29
  • Saludos,

    Pero en este caso tu las entidades lo manejas a nivel de objeto verdad?

    Yo lo hago desde codigo

    Y la verdad no solo se trata que sea de replicar sino que la aplicación ya tenga implementadas clases de conexion a otro motor de BD.

    O sea esto sería un plus de instalacion o al momento de adiquiri yo lo hare en MySQL pero si el cliente quiere Oracle y a ultima hora quiere SQL Server pues que el pueda cambiar de ida facilmente sin hacer el relajo "No pues ud. queria Oracle hice solo Oracle" me explico?

    Creo  que a muchos nos ha tocado un cliente pesadito...


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    domingo, 24 de julio de 2011 22:35
  • Ehh caray, te capte por completo la idea, me senti identificado con tu caso.. jaja :D

    en ese caso reitero con toda seguridad, te conviene trabajar con EF, pues desde ahy pues desde ahy tienes la opcion de trabajar contra TU MODELO CONCEPTUAL, y este modelo lo envias a la base de datos :D ves?? es decir tienes tu proyecto base con todas tus consultas linq To Entities, y cada vez que implementes a un cleinte en especifico puess mapeas al client provider especifico.

    Recuerda que co EF puedes trabajar de distintas formas:

    DataBase First

    Model First

    First Code

    Creo que te convendria investigar al respecto y ver cual te convien (te aconsejo Model First pues aun no soy muy experto con Code First).

    Saludos.     


    Nicolás Herrera
    Bogotá - Colombia
    BLOG - Leader Group BogotaDotNet
    "Daría todo lo que sé, por la mitad de lo que ignoro." Rene Descartes
    • Propuesto como respuesta Nicoloco lunes, 25 de julio de 2011 19:12
    domingo, 24 de julio de 2011 22:45
  • Jajaja gracias yo soy nuevo en 

    DataBase First

    Model First

    First Code

    Ah pero bueno EF me permite mapear con Oracle, SQL Server Nativamente, pero y que pasaría con MySQL,SQLite, Firebird?


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    domingo, 24 de julio de 2011 22:52
  • No te preocupes, hay proveedores de todos los motores de BD... nadie se quiere quedar sin participar de este boom de EF

    Creo que escribire un post en mi blog dedicado a este tema que tanta demanda esta teniendo.

    Por el momento te digo, que empieces por buscar los client providers de esos motores de bases de datos para VS 2010.

    Saludos.  


    Nicolás Herrera
    Bogotá - Colombia
    BLOG - Leader Group BogotaDotNet
    "Daría todo lo que sé, por la mitad de lo que ignoro." Rene Descartes
    domingo, 24 de julio de 2011 23:03
  • Bueno esta bien compa millon gracias pero estas tendencias de desarollo me imagino que esta para descargar con el nuevo Ado EF verdad?

    Estaba leyendo 

    [Entity Framework] Dejando a nuestra capa de acceso a datos

    en tu blog

    o sea se trata de fusionar Entidad y Datos?

    domingo, 24 de julio de 2011 23:05
  • Hola

    - Mira con Visual Studio 2010 ya tienes EF 4.0 instalado y listo para usarlo :D

    - Ahora bien, con EF trabajas contra un modelo conceptual, es decir, mapeas las tablas de tu base de datos a un modelo abstracto que se entiende por si mismo con la BD, por eso digo "Dejando a nuestra capa de acceso a datos" por que ya no tienes que escribir Tus entidades a mano ni escribir consultas SQL quemadas en strings...

    EF te mapea de manera inmediata estas entidades en tu proyecto con todas sus propiedades, llaves primarias y foraneas. y tienes metodos definidos para guardar datos en tu BD.

    Repito, te olvidas por completo de como se trabaja contra la BD pues este potemte ORM lo hace por ti :D .. yo tampoco lo creia pero si!! es magico jajaj

    Animate a usarlo y descubriras todo su potencial, espera mas post's al respecto en mki blog ;D

    Saludos


    Nicolás Herrera
    Bogotá - Colombia
    BLOG - Leader Group BogotaDotNet
    "Daría todo lo que sé, por la mitad de lo que ignoro." Rene Descartes
    • Propuesto como respuesta Nicoloco lunes, 25 de julio de 2011 19:12
    domingo, 24 de julio de 2011 23:43
  • Listo estaré pendiente de tus publicaciones...

    O sea lo que me dices es que todo lo usas cual antiguo datacontrol o ADO control

    Mmmm ya ya, es que yo siempre creaba las entidades a nivel de código querys sencillas a nivel de clases y las mas complejas de lado del servidor


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    domingo, 24 de julio de 2011 23:49
  • estoy de acuerdo con Eduard, es bastante dificil decir cual usar depdje de muchos factores

    como habia comentado en el otro post

    http://social.msdn.microsoft.com/Forums/es/vcses/thread/ce6b5578-bf58-4e21-bb5e-ce1a32865b41

    me gusta mas NH por su estabilidad, porque fue portado de un proyecto que lleva años desarrollado en java, con lo cual le da cierto respaldo, y el saber que hay ideas he implementaciones fuertes, no se va as alir con cosas locas

    es sabido que donde gano EF es al introducir un modelo visual que hace que la curva de aprendizaje sea muy inferior a NH, esto es por lo cual toma ventaja

    sin descartar tambien que al estar integrado, es logico, que no hay quien compita con eso, pero tampoco descartemos de donde saco la idea para tomar lo bueno y lo malo de un ORM y cuantos años lle llevo poner algo para usarse, cuando NH ya hacia años que se podia implementar en los desarrollos

    tambie hay que mencionar que un desarrollo serio no usa modelos graficos, por eso recien ahora con Code First se lo podria estar empezando a mirar con mejroes ojo, pero proque surge esto de modelar con el codigo, porque existe Fluent de NH y esto pega mucho a en los desarrollos serios

    como comente hasta ahora desde mi punto de vista EF era un DataSet tipado pero evolucioando (con la integracion de linq), recien ahora con Code First esta tomando otro color, eso de modelos visuales no me convence para anda en un modelo de perssitencia

     

    otro punto que hay que tener en cuenta en este debate es quien decide la tecnologia que se implementa, es sabido que si le das a elegir a un cliente lo primero que te pregunta es quien respalda la tecnologia?, y que de decis: EF lo respalda Microsoft y NH la comunidad, bueno la seleccion del cliente esta mas que clara

     

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    miércoles, 31 de agosto de 2011 0:39
  • Code First es igual a esto?

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Text;

     

    namespace EL

    {

        public class myEntity

        {

            public myEntity()

            {

                this.Lineas = new List<entLines>();

            }

     

            public int id { get; set; }

            public int idcli { get; set; }

            public DateTime fec { get; set; }

            public string domicilio { get; set; }

     

            public List<entLines> Lineas { get; set; }

     

            public decimal vTotal

            {

                get { return this.Lineas.Sum(x => x.UnitPrice * x.Quantity); }

            }

        }

    }

     


    Nestor Davila Muñoz
    Junior Developer (VB.Net-PostgreSQL-SQLite-ASP.Net)
    "No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    miércoles, 31 de agosto de 2011 0:44
  • No.

    Code-first es hacer tu código antes que tu BBDD. Generar tu BBDD a partir de tus clases. Puedes tener dos códigos idénticos, pero si uno lo generas a partir de un modelo visual (edmx) usando T4 p.ej. entonces estás usando Model First. Si el otro código lo tecleas tu a mano, entonces usas Code First.

    Code First, Model First, Data First... no tienen que ver con el API que uses, sinó en como lo usas.

    Otra cosa es el API que usas. En el caso de EF hay dos grandes APIs (ObjectContext y DbContext) y en el hecho de si nuestras entidades son propias de EF, IPOCO o bien POCO.

    Saludos.


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    miércoles, 31 de agosto de 2011 6:09
  • hola

    si te interesa el tema recomiendo estos videos, son muy simples de enteder Code First de EF

     

    http://www.comunidadesdeusuarios.net/cursos/ef4-120.aspx


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    jueves, 1 de septiembre de 2011 0:32
  • Gracias Leandro En este momento lor eviso
    Nestor Davila Muñoz
    No es mas grande aquel que nunca falla, si no el que nunca se da por vencido"
    jueves, 1 de septiembre de 2011 0:46