On Sun, Jul 18, 2010 at 7:40 AM, Leandro Hermida <[email protected] > wrote:
> Hi t0m, > > On Sun, Jul 18, 2010 at 6:22 AM, Tomas Doran <[email protected]>wrote: > >> >> On 11 Jul 2010, at 14:48, Leandro Hermida wrote: >> >>> I had a look at KiokuDB, its a very nice project and suitable for >>> certain needs, but it doesn't do ORM. In many software development >>> projects particularly business-related you really the database to be a >>> relational implementation of your entity object model because you have >>> other systems, software and programming languages that will be >>> interacting with the database. >>> >> >> Unless you're going to hide the entire actual DB behind views and stored >> procedures, then this is generally a REALLY BAD IDEA. >> >> You now have no level of abstraction from your database layout and your >> data model. >> >> Which means that changing the database layout (without changing all the >> apps which work on that layout at the same time) is going to break things, >> which then need fixing in multiples places, and releasing in sync - I.e. you >> just achieved very very close coupling to your DB schema, which you want to >> avoid (for reasons stated above) if possible... >> >> > very good points and makes a lot of sense. If I can ask a more general > question then, why do ORMs exist in the first place and why are they so > popular vs using a object persistence mechanism? There must be some serious > advantage to using them. > Actually the poster is misleading. When you change the database layout you don't have to change the apps which work on that data model interface - because you already have an abstracting layer between the application and the database. You can extend your ORM implementation to be backwards compatible, so that the actual data store behind it can change but the front face does not. Some find it convenient to have a data model layer between the app and the ORM, but it is not necessary, only one layer is needed. ORMs exist - their killer application - because it is difficult enough to manage your model layer abstractions - which exist regardless of ORM or not - without adding the further complexity to them by changing your semantics into into a new language - SQL in this case. You also bypass the flat table-space paradigm of SQL making your data objects hierarchal per your defined relationships without having to go through the tedium of translating the flat space to the hierarchal space. "But we're comfortable with SQL in our programs!" people shout, that is the way it has been done! It shouldn't be. No more than you should output HTML through print statements in a CGI program! That is a language in a language. You should be able to interact with your data source on a native language level, and this is what the ORM provides. How much code have you written that forms sql up from chunks relevant to a certain type of query? How much code have you written that builds sql table data form returns into various types of objects? Even hierarchal logical ones resulting from a one-to-many join? There is a type of code you don't have to write when you use an ORM - because all that SQL abstraction is done for you already. Your interface is as stable as you want it to be, your application does not have to change when the data store changes - only the model layer between them. - keep the sql out of my perl - keep the data store interface separate from the application - no reinventing the wheel for data store to object instance translation David -- "If only I could get rid of hunger by rubbing my belly" - Diogenes
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
