Business Object design question
Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=783
Printed Date: 13-Apr-2026 at 5:46am
Topic: Business Object design question
Posted By: DapperDanH
Subject: Business Object design question
Date Posted: 24-Apr-2008 at 8:18am
I have a database that looks like this:
| Table Name |
Property |
| Filters |
|
| * |
ID |
| |
Name |
| FilterItems |
|
| * |
ID |
| |
FilterID |
| |
ItemID |
| Items |
|
| * |
ID |
| |
Name |
| |
Property1 |
| |
Property2 |
Basically, I have a list of items…around 4000. Users want to define some named filters, where they “pick” the specific items. So, if the user build a filter called "MyFilter", they then could select items. If they selected 10 out of the 4000 items, the "FilterItems" for MyFilter "Filter" would contain 10 rows.
Ideally, the UI would like something like this:
|
Item Name |
Selected? |
|
Item1 |
X |
|
Item2 |
|
|
Item3 |
X |
|
Item4 |
|
|
Item5 |
|
|
Item6 |
|
|
Item7 |
X |
|
Item8 |
|
|
Item9 |
|
|
Item10 |
|
|
Item11 |
X |
|
Item12 |
|
|
Item13 |
|
|
Item14 |
X |
|
Item15 |
|
|
Item16 |
|
|
Item17 |
|
|
Item…. |
|
|
Item4000 |
|
So, all items would be shown and selectable. However, if you look at the DB design, only selected items are stored. Simply building BO's from tables would not allow me to bind to a grid to get the presentation we desire showing all 4k as selectable. So, my question is, is there a recommended approach to this probably very common use case?
1. Build BO’s on top of a view. If we do this, what is recommended way of updating the FilterItems table?
2. Build separate BO’s that integrate on top of the ORM’s BOs.
3. ???
Curious to your thoughts.
Thanks,
Dan
|
Replies:
Posted By: davidklitzke
Date Posted: 24-Apr-2008 at 9:06pm
|
Show all 4000 items (in a ListBox or perhaps better yet in a grid) and allow multiple selections. Perhaps have a "Create Filter" button. When you create the filter, create a parent filter with a user-specified name. Also create a child filter for all of the possible children, e.g. 1, 3,7,11,14.
In another form, user can pick a filter. Once he/she picks a filter, create an EntityList using the filter.
One final piece of advice: Don't use a view. Views are usually read-only.
|
Posted By: DapperDanH
Date Posted: 25-Apr-2008 at 4:24am
|
David,
Thanks for the reply.
You replied "create a parent filter with a user-specified name. Also create a child filter for all of the possible children, e.g. 1, 3,7,11,14." The parent and child filter you are referring to sound like entities we would code. Are these entities generated using the ORM tool on top of the Filter and FilteredItems tables? or are these entities we create manually and they know how to interact with entities ORM'ed against the Filter and FilteredItems tables?
I am hoping for some more guidance.
Given the database design shown, would I use the ORM tool to map the Filter and FilteredItems tables? If i do map them, then there is a disconnect between the way I want the UI to work and the way the BO is designed. The BO's would be mapped around a nornalized database.
So, to make the UI work like we want, I am thinking I need another set of BO's that sit on top of the ORM'ed BO. If this is correct, then is there a recommended best practice to how to code this?
Thanks,
Dan
|
Posted By: davidklitzke
Date Posted: 25-Apr-2008 at 8:48am
|
The ORM doesn't create entities that don't already have corrresponding tables or views in the database, Therefore, when I said to create a parent filter and the child filters, you could do this by directly creating tables in the database, or by programmatically creating and storing them in the database.
Once you have created the table for the parent filter table and the child filter itable n the database, you would then typically open the ORM Tool to create mapping between the database tables and the Parent and Child Entity.
Some ORM Tools allow you to start from a desgn, and they will generate tables in the database. In DevForce, you almost akways start with the database first.
Once you have created a Parent and a Child Entity and mapped these entities in the ORM Tool, you can then build a UI that can create any number of Parent and Child Entities. For example, let us say that you want to build a UI that will allow a user to build any number of Product Lists. User hits "Create Product List" button. and he then sees a list of all of the products with unchecked checbox beside each product. The user then checks the checkbox for products 1, 4, 7, 10, 11, and 14. The user then hits the "Save Product List" button, and is prompted for a name. The UI then creates the Product List.
|
Posted By: DapperDanH
Date Posted: 25-Apr-2008 at 1:00pm
|
Thanks for replying again.
"User hits "Create Product List" button. and he then sees a list of all of the products with unchecked checbox beside each product."
Assume the "products with unchecked checkboxes" were in a grid. This grid is bound to some entity list (business objects). This entity list would NOT be the same entity list generated from the database. We would essentially create business objects to support our UI needs and then "adapt" that to the business objects that we ORM'ed. Am I understanding correctly?
Assuming that is true, then
1. whenever the schema changes, we would have to update the mapper.
2. Would we derive our UI centric entities from entity list, so we can get some of the benefits of DevForce binding?
Thanks for your patience on this.
Sincerely,
Dan
|
Posted By: davidklitzke
Date Posted: 25-Apr-2008 at 5:00pm
|
You are correct on all counts.
|
|