Matt,

>Suppose I have a customer grid on a form that I only want to show the CustNo and CustName columns, but when I pick on a row, I want to populate textboxes on the form with all other the data fields associated with that customer (i.e. address, phone, fax, etc).
>
>So, the main CustomerEntity obviously would have a property for each column in the underlying table, but I do not want *ALL* those columns in my customer grid. So my plan was to have one "light-weight" *entity list* of CustNo,CustName under one Customer BO, and a fully detailed *entity* under another instance of the Customer BO for the detail textboxes.
>
>I suppose I could use the fully-populated default Entity for the grid, but I will have to learn how to only show certain columns from the BO in a grid. Right now, I am setting the binding source of the grid to the Customer BO object, but I am getting *all* the columns, where I only want the CustNo and CustName.
>
>
>On the matter of creating an entity list of anything thing you want, and letting the default Entity host that, what about the possibility of pulling back a record set with a SELECT statement that has a column that's not in the Entity model? I suppose the "best practice" must be to make sure that your Entity has *ALL* the columns from the table, and then you would be covered?
>
The columns in the Entity class do not have to all be populated when you instantiate the object. If your BO has a select statement such as SELECT CustNo, CustName FROM Customer then that is all the data you get regardless of the class definition. This is still lightweight. As far as the grid goes, yes you can and should pick what the grid columns contain.

So in your case you would have two methods in your Customer Business Object for this page.
GetCustomerNameList() with the select above
And ad GetCustomerByNumber(int custNo) with a SELECT * FROM Customer WHERE CustNo = @CustNo,
this.CreateParameter("@CustNo", custoNo));
both of these methods would be in the same BO and use the same entity model.

Keep in mind, you can always just return a dataset from the BO also.

I have done this very thing many times within the same BO and using the same Entity objects.
I hope this helps
Tim

>
>
>>OK Matt,
>>
>>
>>>It sure seems like the MM framework would have a naitive way to deal with this.
>>>
>>>Here is what the MM Dev Guide says:
>>>----------------------------------------------------------------
>>>This architecture also allows the business object to return different "shapes" of entity objects. For example, you can return an entity object that has all properties corresponding to columns in a data table when you want to edit, or you can return an entity object that only has a primary key and description when binding to read-only lists.
>>>----------------------------------------------------------------
>>
>>First of all you do not need to have a different Entity class in order to return Entity objects with different shapes as suggested above. You can have a method in your BizObj that fills an Entity with all columns and a different method that returns only a couple of the columns. Kevin has set the Entity Object up so it can accept a partial column set of data.
>>
>>So, I did try howeve what I suggested and it doesn't work because when you override the method it resolves to a specific class type. It could be done, but as you say not worth the effort and it doesn't really make sense. I then wondered what exactly was the need you were trying to do. I re-looked at your post and I am not exactly sure. The business object it self is pretty flexible because all the specific code is what you put in there and it can be used as needed or not. The entity is only a representation of data, so if you include all the fields in the associated table you have the flexibility to retrieve all the columns or only part of them. You also have the ability to return a single entity or a list. I can't think of a reason to actually have different entity classes.
>>
>>Since I bit the bait on this one, can you give me more detail on what you are thinking you need to do? I will help if I can.
>>Thanks
>>Tim
>>
>>>Now then..
>>>
>>>I don't understand how your suggestion will handle this matter... In looking at the BO class code, the Customer class seems to define its Entity object specifically based on the default CustomerEntity class that was defined in my Customer.Partial.cs file by the BusinessLayerGeneterator tool (i.e. the default Entity class). So, how would you use the CreateEntityObject() method to create a different Entity that the very type of entity on which the Entity class is being defined as?
>>>
>>>Also, all the custom GetEntity() and GetEntityList() methods that you define in the Customer.Partial.cs are also of the type CustomerEntity. So there is another area where you would have to deal with altering type of entity you want these methods to generate and return.
>>>
>>>
>>>Obviously, there are a few things I don't understand yet. Any insight you can provide is greatly appreciated.
>>>
>>>
>>>
>>>
>>>>Matt,
>>>>
>>>>Override the factory CreateEntityObject()and put a decision in there. You could set a property to drive the decision as one method.
>>>>
>>>>Tim
>>>>
>>>>>I read in the Dev Guide about "Working with Different Shaped Entities", and I think I need to do this in a few cases, so... How do you tell the Business Object *WHICH* Entity to use when it is instantiated? I see how to create additional Entity "shapes" using the Business Layer Generator, but how do I create an instance of a my Customer BO on one form that is based on the default Entitiy, but also have a Customer BO on another form that is based off a different Entity definition?
>>>>>
>>>>>In looking at my Customer.cs code file for the Customer BO, it seems to pretty much be hard-coded to use the default CustomerEntity entity class.
>>>>>
>>>>>Also, can you switch between Entities within one instance of a BO object?
>>>>>
>>>>>Code below is from Customer.cs:
>>>>>
>>>>>
>>>>> public partial class Customer : ABusinessObject
>>>>> {
>>>>>
>>>>> #region Association Properties
>>>>>
>>>>> ///

>>>>> /// Business Entity object
>>>>> ///

>>>>> public override CustomerEntity Entity
>>>>> {
>>>>> get
>>>>> {
>>>>> if (this._entity == null)
>>>>> {
>>>>> this._entity = this.CreateEntityObject();
>>>>> }
>>>>> this._entity.SetDataRow(this.DataRow);
>>>>> return this._entity;
>>>>> }
>>>>> set
>>>>> {
>>>>> this._entity = value;
>>>>> if (this._entity != null)
>>>>> this.DataRow = this._entity.GetDataRow();
>>>>> else
>>>>> this.DataRow = null;
>>>>> }
>>>>> }
>>>>> private CustomerEntity _entity;

Timothy Bryan