Hi, I am building my Business Objects and as I am new on it I am tryin to figure out what are the best practices on turning a table that manages a many-to-many relationship into a Business Object. If someone has any hint for me, I appreciate.

Thanks.

I'd recommend you try and find a Business Objects forum, as this one is devoted to C#.

/- Sam Judson : Wrox Technical Editor -/

The design pattern that deals with that structure is called the 'mediator pattern'. Suggest you search for examples online.

--

Joe (Microsoft MVP - XML)

OK, I feel stupid now - I thought you where referring to Business Objects - the reporting tool.

In most many-to-many relationships I have come across there is a link table joining the two tables, so that would mean you would model the link table as well.

If you need more specific advice then you'll have to detail examples of your tables etc.

/- Sam Judson : Wrox Technical Editor -/

Thanks for the replys. The structure of my tables is something like this:

Work
(PK) idWork
Description
Code

DocumentType
(PK) idDocumentType
Description

And, as this tables must have a many-to-many relationship, the link table:

WorkDocumentType
(PK) idWorkDocumentType
(FK) idWork
(FK) idDocumentType
Code

The reason I have to do it, is because that, for every new Work, the Code fields of DocumentType will be different. The problem I am facing is that a I don't know the correct way to create the BOs for those tables.

And I am tryin to understand the Mediator pattern and it seems this is what I need, but if anyone else have any other way possible, I appreciate.

Thanks again.

You need to structure the business objects such that they make sense for your business model. If you work from the prospective of "Work" then the "Work" class would have a property containing a list of "Document"s.

You don't necessarily need to model the junction table in your business object library because there is very little meaning to it. It simply serves to join together related instances of "Work" and "Document".

-Peter
compiledthoughts.com

Keep in mind that the point of BOs is to let you remove highly specific application code from specific webpages as you have to do when using Data Sources. BOs free you from tying an implementation to each and every page where you want to use it making it easier to use database data in your application and to maintain the application when you decide to make changes. You now do it in one business object instead of many pages, but the BO is still an application component. The tables are still set up in your database, and the BO simply "automates" features of how you use that data in your application. I'm just starting to look at them myself and find them very exciting.

-------------------------

Whatever you can do or dream you can, begin it. Boldness has genius, power and magic in it. Begin it now.
-Johann von Goethe

When Two Hearts Race... Both Win.
-Dove Chocolate Wrapper

Chroniclemaster1, Founder of www.EarthChronicle.com
A Growing History of our Planet, by our Planet, for our Planet.