Suggestion: Parent Property in IParent interface

Suggestion: Parent Property in IParent interface

Old forum URL: forums.lhotka.net/forums/t/9970.aspx


itracker posted on Friday, January 21, 2011

Hello!

Could you add property Parent in IParent interface? Without this property we take Parent value and cast it to our BusinessObject. And in some situations its prevents polymorphism :(

RockfordLhotka replied on Monday, January 24, 2011

Good idea. I will add this to the wish list.

ajj3085 replied on Tuesday, January 25, 2011

Should there be an IChild interface?  Or even just put this on IEditableBusinessObject?  I thought IParent meant the implementor WAS a part, not has a parent.

itracker replied on Tuesday, January 25, 2011

This property should be in the BusinessListBase too. And why I cant't get parent in ReadOnlyBase and ReadOnlyListBase? because of this we are forced to use BusinessListBase and BusinessBase :(

RockfordLhotka replied on Wednesday, January 26, 2011

The Parent property does exist in BusinessListBase - I assume you aren't using CSLA 4?

It is true that ROB and ROLB don't have this property. They also don't have business rules. What is the scenario where a Parent property is required in read-only objects? The whole point of the read-only stereotypes is to minimize overhead, but if there's a broad and compelling scenario where lots of people need a Parent property in read-only objects I'd consider adding this bit of overhead to the base classes.

itracker replied on Wednesday, January 26, 2011

1. BusinessListBase is generic. How I can access to it when i dont'now they actual generic parameters ? Our children businessbase object may have different parents.

2. We are hold readonly dictionaries in readonly root object. This readonly root object cached on client and fetched when application is boots.  Dictionaries linked with each other. And almost every dictionary business object has computable plain .net properties.

Example:

Dictionary1: Countries,  Dictionary2: Cities

We have two comboboxes: country, city. When user select country, city combobox should filter itemssource by selected country. We bind cities ItemsSource to CountryDictionartItemBusinessBase.Cities property. Property "Cities" is computable and uses Cities dictionary through Parent property. We have to use Editable objects in this scenario because ROB and ROLB does not have Parent property :(

tmg4340 replied on Wednesday, January 26, 2011

I may be misunderstanding your post, but I think you're using CSLA objects in a way they weren't entirely designed for.

CSLA objects are designed to follow a "one parent" philosophy.  If you have child objects in a collection that do not all have the same parent, you're going to work against the CSLA design philosophy.

As for your linked-dictionary example, I'm not exactly sure why you would do it that way.  If you always use cities in the context of a country selection, then it should be built as a standard parent/child reference.  If you use the lists independently, then you shouldn't try to link them via a Parent property - you should build methods on the objects that you call to get the appropriate objects for your other selection (a "GetCitiesByCountry" method, for example).  It's a using versus a containment relationship.  Having a parent implies containment.

HTH

- Scott

RockfordLhotka replied on Wednesday, January 26, 2011

Scott is correct. The CSLA base classes exist to support specific object stereotypes (see Using CSLA 4: Creating Business Objects for details). The stereotypes always assume a single root parent object for the object graph, and read-only objects are intended to be immutable.

I understand the need for caching. What I'd do is implement a UoW object that gets the information you want to cache - probably as a set of read-only lists.

Then I'd implement the actual name/value or read-only list objects used by your use cases, and I'd have their "data access" code always run locally (which means it will run on the client). That data access code would populate the objects from the cached values.

This provides much cleaner separation of concerns - keeping the concepts of data caching away from the concepts of providing a logical object model that meets the needs of each use case, while also providing high performance.

LINQ queries and the data portal make this pretty trivial to implement.

itracker replied on Wednesday, January 26, 2011

You are misunderstood. We have only one parent per business object. But In each silverlight page object graph fethed separately. And children business classes just reused and parents may be differents. But we have common interface for our root objects IOurRootObject with common Properties for all silver pages. And I want to access to this IOurRootObject in childrens through Parent properties.

About caching. We use CslaViewModel per silverlight page. And this view model operate fith single BusinessObject. Your alternative is to use two business objects and two models. That is not very convenient

Copyright (c) Marimer LLC