> data isn't read into the objects out of nothing when
> you want it, you have to order some code to get it
In our persistent framework, merely copying a object's properties doesn't
cause objects to load, once on those properties is "dotted", that causes the
object to be transparently loaded. It's sometimes a VERY efficient way to
deal with objects, and sometimes not. When we're carrying lists of objects
around, and only referencing some attributes of them, we don't load the
other attributes (and related objects)--which is fast. When we do deref
those objects, the get loaded (once per scope) in multiple
transactions--which is slow.
But the important point here is that NONE of our code knows how objects are
joined together, what table(s) they are in, what the column names, or indeed
the data types of the columns are. If an object happens to span a couple of
tables, and reference a dozen more, querying for the interesting objects and
loading them (lazily) happens automatically with code like this:
string StateToFind = 'MO';
Framework.Query findCustomers = new Framework.Query("this", "that");
findCustomers.SetId(Customers.Attributes.CustomerId);
findCustomers.AddWhereClause(findCustomers.FormatEquals(Address.Attributes.S
tate, StateToFind));
findCustomers.AddWhereClause(findCustomers.FormatBegins(Customer.Attributes.
LastName, "Brooks");
findCustomers.AddOrderBy(Customer.Attributes.LastName);
findCustomers.AddOrderBy(Customer.Attributes.FirstName);
findCustomers.AddOrderBy(Customer.Attributes.AddedWhen, DESCENDING);
Framework.IPersistantObjectList matchingCustomers =
findCustomers.GetList(50);
will automatically generate this SQL for SQL Server (and the appropriate
other formats for Informix, and DB2, just by sniffing the connection
provider):
SELECT TOP 50
Customers.Id
, Customers.LName
, Customers.FName
, TransLog.AddDate
FROM Customers
INNER JOIN Addresses
ON Customers.CustAddrId = Addresses.Id
AND Addresses.State = 'MO'
INNER JOIN TransLog
ON Customers.Id = TransLog.ObjectId
WHERE
Customers.LName LIKE 'Brooks%'
ORDER BY
Customers.LName ASC
, Customers.FName ASC
, TransLog DESC;
That's pretty good for some mark-up attributes and a lookup table (actual
table/column names are in a table in that database itself). Since all the
object IDs include the "type number" of the object, then required SQL to
load an object is automatically generated. It's much like what the ODMG
described eons ago, and we've got a C++ and C# implementation of it. Again,
things that need to load large numbers of rows, should NOT use these lazy
instantiations, but I think of that as the realm of stored procedures
anyway.
Marc
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
