Public Person(Session session) : base(session) Ĭonst string connStr = "Integrated Security=SSPI Pooling=false Data Source=(local) Initial Catalog=XpoTddTest" This is all you need to do to start writing your domain objects (try do the same in other systems): using System But in general XPO became quite convenient to use. You can still hit problems while working with legacy DB. no support for db schema in postrgeSql providerĪll in all, XPO was greatly improved. DevExpress eXpress Persistent Objects (XPO) ORM for.no support for enums in postgreSql provider - You just need to write really simple value converter and you are good.Īlso, below issues will no longer be problem with next XPO release, coming later this year:.Xpo wants specific name for such interim tables. You can use XPO to retrieve data from a data source, and the XPObjectSource component to bind reports to this data. you cannot do many-to-many relation mapping with your own interim table.XPO supports now various serialization scenarios and can be easily used with WCF. no serialization, so XPO objects are hard to use in disconected win forms scenario, with data coming through web services.In particular, below things are no longer an issue: They are considered to be "anti-ORM" pattern.Īs Dennis pointed out in comments, XPO was greatly improved since I wrote this answer originally. To be fair, no ORM handles composite keys nicely. Poor support for foreign composite keys.no support for pre filtering associations, which can cause excessive network load.It's possible, but you need to do a little hacking to stop XPO from updating field in DB no support for readonly persistent fields OOTB.all objects need to inherit from XPO related classes and/or use XPO related attributes.However, it can be a little pain when you plan to work with legacy database or try to introduce it into a brownfield app. XPO comes from a tools vendor, are they likely to remain in business for the lifetime of the product?ĪDO.NET Entity Framework comes from Microsoft, who are notorious for changing database technologies more often then Larry fills his fighter with jet fuel - will this, too, fade away? In practice, though, all are good I'd most likely look at the commercial situation for the project ahead of the technical questions.įor instance, NHibernate is open-source - is there a viable community there to support the tool and to provide (if necessary) commercial support? If I were starting afresh I'd definitely look at both NHibernate and the ADO.NET Entity Framework. I don't see any need to change at the moment, as our data volumes aren't particularly large and the foibles (caching, mostly) are things we can work around. I find that it's fast, flexible and does the job. I've used XPO successfully for years in an established commercial product with several hundred users. the query syntax, use of caching, ease or otherwise of mapping to an existing database structure) - but if you have an established ORM layer the answer is probably Others will probably pitch in with technical answers (e.g.
0 kommentar(er)
