c# - ¿Alguna idea sobre DevExpress XPO ORM Package?

windows

Question

XPO es el mapeador relacional de objetos de elección en mi empresa. ¿Alguna idea sobre los pros y los contras?

Solo buscaba sentimientos generales y anécdotas sobre el producto. No estamos cambiando a XPO. Nos estamos deshaciendo de las cadenas sql codificadas que viven en la aplicación y se mueven completamente a ORM para todo acceso a datos.

Answer 1

Los pros y los contras en comparación con qué? Hay muchas alternativas, la más popular es nHibernate, con el nuevo Kid ''ADO.NET Entity Framework'' en el bloque.

De todos modos, hay cientos de respuestas dependiendo de su situación y requisitos.

Answer 2

Es probable que otros colaboren con las respuestas técnicas (por ejemplo, la sintaxis de la consulta, el uso del almacenamiento en caché, la facilidad o la cartografía de una estructura de base de datos existente), pero si tiene una capa de ORM establecida, la respuesta es probablemente

"Por qué cambiar"?

Utilicé XPO con éxito durante años en un producto comercial establecido con varios cientos de usuarios. Me parece que es rápido, flexible y hace el trabajo. No veo ninguna necesidad de cambiar en este momento, ya que nuestros volúmenes de datos no son particularmente grandes y los puntos débiles (el almacenamiento en caché, en su mayoría) son cosas que podemos solucionar.

Si comenzara de nuevo definitivamente miraría tanto a NHibernate como a ADO.NET Entity Framework. En la práctica, sin embargo, todos son buenos; Lo más probable es que mire la situación comercial del proyecto antes de las preguntas técnicas.

Por ejemplo, NHibernate es de código abierto: ¿existe allí una comunidad viable para respaldar la herramienta y proporcionar (de ser necesario) soporte comercial?

XPO proviene de un proveedor de herramientas, ¿es probable que permanezcan en el negocio durante la vida útil del producto?

ADO.NET Entity Framework proviene de Microsoft, que es famoso por cambiar las tecnologías de las bases de datos con mayor frecuencia que Larry llena su caza con combustible para aviones: ¿esto también se desvanecerá?

Answer 3

Me gusta el hecho de que solo puede crear clases y xpo crea las tablas y relaciones para usted, de modo que puede comenzar desde una base de datos en blanco.

Un problema que no me gusta es cuando quiero eliminar un montón de cosas, pasará por mi colección y hará una eliminación en cada una. Esto lleva años, así que para este tipo de instancia, he tenido que escribir algunos sql personalizados (eliminar de la tabla donde bla). No soy un experto en XPO, pero eso es lo que encontré.

Answer 4

En segundo lugar, el hecho de borrar objetos complejos con algunas colecciones lleva mucho, mucho tiempo. Hasta ahora, la documentación o los foros no han podido ayudarme con esto.

Aparte de eso, es realmente simple de usar y te pone en marcha rápidamente.

También es bastante difícil entender el uso de la memoria, tenía objetos grandes y complejos en mi diseño y trabajar con ellos era un recuerdo más grande de lo que había supuesto.

Answer 5

He encontrado XPO muy frustrante para trabajar. La idea principal de un ORM es abstraer la estructura de datos subyacente. Pero muy pronto notarán que tienen la longitud de cadena predeterminada codificada en 60 caracteres, por lo que terminan agregando estas cadenas feas. Cosas ilimitadas alrededor de cada cadena. Tanto para la abstracción ...

Al modelar objetos más complejos, debe usar mucha sintaxis que realmente no tiene cabida en su modelo de objetos, como XPCollection. Quería almacenar una clase que tuviera un diccionario de cadenas en la clase, pero lamentablemente XPO no pudo almacenar esto automáticamente en la base de datos.

Entonces, si bien funciona bien para los tipos simples, se descompone muy rápidamente cuando quieres almacenar cosas más complejas. Eso combinado con su soporte mediocre realmente deja mucho que desear.

Answer 6

He estado trabajando con eso durante 6-7 meses y el vendedor para mí fue el hecho de que todos sus componentes de interfaz de usuario funcionan de forma relativamente sencilla con XPO, y sus componentes de interfaz de usuario son de primera clase.

Algunos podrían notar que sus foros están mal monitoreados y tienen poco tráfico útil, esto es cierto. El secreto es completar las entradas sin embargo. Responden rápidamente y con precisión a todos sus tickets de soporte.

Answer 7

Esto es todo lo que necesita hacer para comenzar a escribir sus objetos de dominio (intente hacer lo mismo en otros sistemas):

using System;
using DevExpress.Xpo;
using DevExpress.Data.Filtering;
using NUnit.Framework;
namespace XpoTdd {
public class Person:XPObject {
public Person(Session session) : base(session) { }
public string FirstName { get; set; }
public string LastName { get; set; }
[Persistent]
public string FullName { get { return FirstName + " " + LastName; } }
}
[TestFixture]
public class PersonTests {
[Test]
public void TestPersistence() {
const string connStr = "Integrated Security=SSPI;Pooling=false;Data Source=(local);Initial Catalog=XpoTddTest";
UnitOfWork session1 = new UnitOfWork();
session1.ConnectionString = connStr;
Person me = new Person(session1);
me.FirstName = "Roman";
me.LastName = "Eremin";
session1.CommitChanges();
UnitOfWork session2 = new UnitOfWork();
session2.ConnectionString = connStr;
me = session2.FindObject<Person>(CriteriaOperator.Parse("FullName = ''Roman Eremin''"));
Assert.AreEqual("Roman Eremin", me.FullName);
}
}
}

Answer 8

XPO ver 10.2 ahora es compatible tanto con StoredProcedures como con SqlQueries. Ver información aquí ...

Answer 9

XPO en general es fácil de trabajar. Sin embargo, puede ser un poco doloroso cuando planeas trabajar con una base de datos heredada o intentar introducirla en una aplicación brownfield. La mayoría de los obstáculos dolorosos que golpeé fueron:

• todos los objetos necesitan heredar de las clases relacionadas con XPO y / o usar atributos relacionados con XPO. Entonces, no hay objetos POCO
• sin soporte para campos persistentes de solo lectura OOTB. Es posible, pero necesitas hacer un poco de piratería para evitar que XPO actualice el campo en DB
• no admite asociaciones de prefiltrado, lo que puede provocar una carga de red excesiva
• Soporte deficiente para claves compuestas extranjeras. Para ser justos, ningún ORM maneja bien las claves compuestas. Se consideran patrones "anti-ORM".
• algunas pequeñas molestias

Como Dennis señaló en los comentarios, XPO mejoró mucho desde que escribí esta respuesta originalmente. En particular, a continuación las cosas ya no son un problema:

• no hay serialización, por lo que los objetos XPO son difíciles de usar en el escenario de formularios de victoria desconectados, y los datos provienen de los servicios web. - XPO admite ahora varios escenarios de serialización y se puede usar fácilmente con WCF.
• no puede hacer un mapeo de relaciones de muchos a muchos con su propia tabla provisional. Xpo quiere un nombre específico para tales tablas provisionales. - Esto ya no es un caso
• no hay soporte para enumeraciones en el proveedor de postgreSql: solo necesitas escribir un convertidor de valor realmente simple y estás bien.

Además, los siguientes problemas ya no serán un problema con la próxima versión de XPO, que llegará más adelante este año:

• no hay soporte para claves de tipo largo
• no hay soporte para el esquema db en el proveedor postrgeSql

En general, XPO fue mejorado en gran medida. La mayoría de los obstáculos dolorosos fueron eliminados. Todavía puede tener problemas al trabajar con DB heredado. Pero, en general, XPO se convirtió en muy conveniente de usar.