On Tue, 2002-02-26 at 16:59, Terrence Brannon wrote: > Perspective 1: The DBIx::AnyDBD approach (a DBI core solution) > The database is an object. Your perl program contains the methods > which manipulate the object. > ... > > Perspective 2: The "Object-Relational" Approach (based on DBI, > but not core. found in several modules - > Class::DBI, Tangram, BingoX::Carbon, SPOPS). > ... > > Perspective 3: The DBIx::Recordset approach > ... > > My Opinion: > > Perspectives 1 and 3 have an added bonus. They are database independant. > > Perspective 1 uses static SQL. Perspective Three dynamically > creates SQL. > > Perspective 2 offers what are known as "persistent business > objects". I personally favor business actions on a database > object instead, but would like to hear your viewpoints, > especially considering that the p5ee projects seems to favor > perspective two. > > Alzabo has some aspects of Perspective 2 and some of Perspective 3.
I favor composition (has-a) over inheritance (is-a) almost any day of the week. Inheritance can get complicated very quickly, is more difficult to understand and can box you into an awkward design. IMO, objects in an environment P5EE is discussing should be able to get its datasource (database connection, LDAP connection, whatever) from the environment. But to be honest I don't think it matters. The object shouldn't care where the database handle comes from, just that it has access to the database handle or some other object which actually knows how to save the object's state somewhere else. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.