Identity Projections in LINQ to CSLA.NET do wonderful job while binding to data controls.
But this can't be achieved when LINQ query is a join (working with CSLA version 3.8.4).
I can see the reasons behind the limitation, but unfortunately this is exactly what my application needs.
I need to join, and I need to bind to UI controls.
Now what I'm thinking about is some "fake" CSLA objects, that would appear as an entity towards UI (doing LINQ to CSLA.NET Identity Projections), but internally it would decompose into a few "real" CSLA classes, with some kind of automatic dependencies linking them.
Kind of manual join, preserving the merits of Identity Projections.
Does this sound as a good idea solving the situation? (and if yes then is there something handy in CSLA to use, to get these automatic dependedncies going? or anyone having solved something similar somehow?)
thank you,
Andres
Business objects should be designed to match the needs of the use case or user scenario. Which is a fancy way of saying that if you need to do joins across business domain objects to get them into the right shape, then you didn't do a good job of object design.
Joining data entity objects makes sense, they are often in the wrong shape because some tool created them based on the shape of the database.
But business domain objects should have been designed from the start to match the needs of the user scenario, and therefore should be in the right shape - kind of by definitiion.
thank you, this makes me thinking indeed.
By the way, the real reason behind these joins is that I have different data sources that I have to blend into a single datagrid.
Data sources are like live stock data, which I have to blend together with editable sql-stored data (against that same stock symbol). And yet another live source against a given symbol.
I have to think whats the good design here, at some point it obviously has to branch, but where...
Andres
This is the purpose of the data access layer - to encapsulate mapping of data from your data sources into and out of your business domain objects.
Copyright (c) Marimer LLC