Anybody tried using CSLA with Intersystems Caché PostRelational database? Seems like it could be a good fit: object/relational db, often faster than msql/oracle, there's a .NET provider, can use SQL for reporting but stick with objects for developing without using an OR mapper.
Anyone have some experience to share about it?
Thanks,
L
I have not. However, you need to be aware that ODBMS systems aren't a silver bullet. You still must store the data using a relational model, even if the data is stored in "objects" instead of "tables".
Due to this, you still face the impedance mismatch problem, where you need to map the relational data model into your behavioral object model... The core nature of the problem remains unchanged.
It just takes a minute to understand why ODBMS's don't solve the relational problem.
Consider Customer. You create and store Customer objects. All is well.
Then Order includes a customer name value. Your Order object has a CustomerName field, and so this field is part of Order. But now you have the customer name data in two objects -which effectively means two "tables". So when you change Customer.CustomerName, it has no impact on Order.CustomerName. Oops.
Of course I haven't seen Cache', so perhaps they have some way to resolve this. I've thought about the problem off and on, and the only real solution I can see is a database where every individual field is stored as a first-class entity. Then the concept of an "object" (or a "table" for that matter) becomes a virtual view of fields. There are a host of problems with doing this, but it would certainly allow Customer and Order to share the same CustomerName field and get the expected result.
Hi Rocky,
Caché pretends (emphasis on pretends) to escape that mismatch because they are neither relational nor object but multidimensional. They call themselves "post-relational" (which is just a marketing thing that does not mean anything you can really chew). Since they are in fact using multidimentional arrays it may be that each field is in fact stored as a first class entity. At least it seems like it from the language structure (comes from the M language as in MUMPS). You can access Caché directly with objects or through sql queries. Methods can be seen as stored procedures, etc. but then you loose true object modeling and they warn againts it.
I don't know how they design their objects nor if they are truly objects or just data containers. In fact, I don't know much yet. They pretend to much and I have seen a product using it that scales beautifully with hundreds of users, has a large and stable installed base and the developers are Object/Caché junkies. Since anything can be used for a front end and Caché also provides a .Net provider that can use both interfaces (sql queries or object queries), I wondered about using it with CSLA since we already have a large project under way with CSLA and may want to integrate with them.
I admit I had to google for Caché & MUMPS to know what they were talking about.
L
pelinville,
> If Cache can take that object model and infer the foriegn key relationship
> between Order and Customer so that you can
> "Select Order.CustomerName from Order" that would be very impressive!
It seems to be able to do it. When using SQL access you can use either ANSI SQL or "Object Extended SQL". OE-SQL lets you do things like this:
SELECTCustomer->FullName,Customer->SalesMarket->Descr, Valus,SalesItem->InvData, SalesItem->InvNumberFROM MainSalesWHERE Product->Descr = 'Hammer'
The same SELECT in standard SQL is this (could do it with ANSI "LEFT JOIN" instead of non ansi *=):
SELECT SC.FullName, SM.Descr, MS.Value,
SI.InvDate, SI.InvNumber
FROM MainSales MS, SalesItemSI, SalesProduct SP,
Sales Customer SC, SalesMarket SM
WHERE SI.SalesItemID *=MS.SalesItem
AND SP.SalesProductID *=MS.Product
AND SC.SalesCustomerID *=MS.Customer
AND SM.SalesMarketID *= SC.SalesMarket
AND SP.DESCR = "Hammer"
But if you use the object interface instead you query through proxies (proxy code can be generated) and you get back objects. No SQL involved. Still don't know if its mainly DTOs or if the designing part can really be object oriented. Seems the design can be done through any interface. Thus using SQL (CREATE TABLE...) would bring a data bound design (1 object = 1 class) but using the object interface (which they recommend) would enable true object oriented design. Don't understand that part yet (can we design directly in multidimentional using M?)
weird...
Copyright (c) Marimer LLC