http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660How is applying a service endpoint to a relational database different than directly using an XML database such as eXist? I realize you probably wouldn't favor an XML database given this post, but it tends to more easily lend itself to OOP persistence. Certainly, Evan's points related to transactions are important, but using a Unit of Work pattern could relieve that problem. I really like this approach as it seems to ease the object-relational impedance mismatch. Well... almost. http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment5http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment5Sun, 28 Dec 2008 22:06:15 GMTIt also opens up some nasty scenarios with concurrency. With the database exposed as a service, you have to look at how you are going to manage transactions across the service boundary. Either that or tell your service consumers that data loss will result from interleaved read/writes. http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment4http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment4Sun, 14 Dec 2008 06:01:23 GMTHi, Sometime ago I started to make a small scale test of putting the domain objects in a ASP.NET MVC app and using Rails to access them using a REST, and it worked, but it was just a spike to learn more about routing. But this post makes me wonder, it's OK to expose domain objects? If the services are protected inside a controlled network, not meant to be public at all, it's still considered bad design? Do you have any suggestions to make this two worlds talk? Thanks a lot. http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment3http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment3Fri, 12 Dec 2008 11:18:12 GMTRafalG, The scenario is discouraged from design point of view. It is useful in cases, and anyway persistence framework should not affect how you design things. http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment2http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment2Thu, 11 Dec 2008 16:00:00 GMTThe first idea I got from your post is that you're contradicting yourself somehow. You said some time ago that Microsoft Entity Framework's support for disconnected data objects is broken. Today you say that directly exposing data objects through external interfaces is a bad practice. So the conclusion is: Microsoft EF is broken because it doesn't properly support disconnected data. But that's good because disconnected DAOs are evil. :) So EF is not broken - it's just idiot proof :) http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment1http://ayende.com/3747/the-database-as-a-service-anti-pattern#comment1Thu, 11 Dec 2008 09:23:06 GMT