I have a SearchResults object, ReadOnlyCollectionBase. You call .GetSearchResults and pass in a SearchCriteria object and you receive back a collection of SearchResultInfo objects (ReadOnlyBase). This object contains basic search information. Well now my users want more information. We actually have to provide in a web service the ability to return any of our fields from the product (a few hundred fields in the object). So now I need SearchResults to be able to return complete Product objects instead of limited information SearchResultInfo objects.
I'm trying to figure out the best way to do this.
I can create a completely new object called SearchResults_AllFields and isntead of it being a collection of SearchResultInfo objects it will be a collection of the complete Product Objects, much, much larger. The first problem is that Product is not read-only and i think that seems a bit inconsistent. Second, I have a ton of logic in the SearchResults BO that I would have to duplicate. I suppose I could abstract class it.
Or, I could stick with the SearchResults object as it is, but in my web service, when users need that other information I can iterate through teh SearchResults objects, grab the Product_ID, then get the Product Object for each item. Then as i'm iterating through generate an XML document to return with just the fields that they want (from a FieldGroupID they pass in). This seems like a somewhat clean way to do it, mostly with existing objects I alreayd have, but it doesn't seem like it's going to be good performance wise.
I was thinking of keeping everything in same collection and passing back limited SearchResultInfo fields or full Product fields depending on which method is called, but that just "seems" a little kludgy.
Anyone have any opinions on which way they would go? Or another suggestions completely?
Like you implied already - it depends. I've done both.
If I need to display the information up front (like is a grid) or I know all the information will end up being needed anyway (so I don't want to keep "hitting" the database for it), then I create a relatively large Info object - all the details I need in a read only object. Usually, this means I end up with additional .Get methods on my ReadOnlyCollectionBase object as well in order to make an attempt to reduce the number of records I am slugging back across the network (like .GetSearchResultsByProductType, .GetSearchResultsByRegion, .GetSearchResultsByOrderTaker, etc.).
The other way is to keep the Info object extremely light, but make sure to include the ProductID. When they move from row to row, then I get the Product object (by ID) and display it below (or wait until they click a display button). Yes, this could be a lot of hits across the network - but it depends on how they are using the collection of Info object. If they just scroll through the list looking for something in particular and only click on what they are looking for, then the Product object is only fetched when they select the Info object in the grid (you can help control this by not even fetching the Product object until they click a display button or double-click the grid). The trick is to make sure you have just enough information in your Info object so they can intelligently make a decision on when to get the rest of the Product detail information.
I normally have at least three CSLA objects for every "object" I need to work with. In your case, I would have a ProductInfo ReadOnlyBase object (your SearchResultInfo), a ProductList ReadOnlyListBase object (your SearchResults object), and then the core Product BusinessBase object (matching your Product object). The skill is designing the ProductInfo object so that I can use it everywhere I need it - grids, combobox picklists, etc). There might be an extreme case where I would need a fourth object (another Info object) such as you are describing above; however, I try to get around it so I have less maintenance / upkeep. In fact, I don't use the Name / Value pair objects Rocky talks about for drop downs and the like because I find I can make use of the List / Info objects instead. Yes, these objects are a bit bigger than the Name / value pairs ones; however, I can usually cache my List objects so I don't think I am paying that big a price for doing so.
Just out of curiosity, why is there so much logic in your SearchResults ReadOnlyCollectionBase object? Since it is ReadOnly, the only thing you really should need to worry about is Authorization - both on a field basis as well as the entire object as a whole.
Ken
Copyright (c) Marimer LLC