Hi

Let's say I have the following simple realtionship in a domain where a Customer holds a list of Orders, but the Order does not have a relationship back to Customer:

   public class Customer : XPObject
   {
      public Customer() { }
      public Customer(Session session) : base(session) { }

      public XPCollection<Order> Orders
      {
         get { return GetCollection<Order>("Orders"); }
      }
   }

   public class Order : XPObject
   {
      public Order() { }
      public Order(Session session) : base(session) { }

      private DateTime date;
      public DateTime Date
      {
         get { return date; }
         set { SetPropertyValue("Date", ref date, value); }
      }
    }

When I test this it raises a RequiredAttributeMissingException.  But, if I add the [Association("Customer-Orders")] to Customer.Orders I get: "There is a malformed association 'Customer-Orders'. Cannot find the associated member for 'ObjectModel.UnmarkedCustomer.Orders' in the class 'ObjectModel.Order'".

Does XPO only support two-way associations when one side is a collection of persistent objects, or am I missing something?

Thanks

Sean

Hi Sean,

One can't get a collection of Orders for a Customer if each Order hasn't been associated with a Customer.  That's the relational model - and XPO is an Object *Relational* Mapping tool.

An Order needs to be associated with a Customer, and one can do so just by adding a field or property of type Customer to Order.  Doing so, one can navigate from Order to Customer - no [Association] required.

If you also want to navigate from Customer to Orders, then you have to create a one-to-many association as shown here.

-- Alex Hoffman
expressapp.blogspot.com

Hi Alex

Wow - I am shocked that XPO forces you to implement a reverse link - this is not the behaviour of any other ORM of which I am aware!  I understand that the relational side of the mapping is always two way by its nature, but the object side is certainly not always two way and neither should it need to be.

Thanks for the response :)

Sean

Hi Shaun,

Dont be shocked!

XPO isn't a real mapper that lets you develop the object and relational models independently and merely define a mapping between them.  So there are some constraints on how you model your objects, including not being able to have your one-sided "containment" (one-to-many) in your object model automatically map to the relational structure.

It's sweet spot is new application data development, rather than mapping to an existing database schema.  For new development, working with XPO (and working it's way) can be *really* productive for a whole bunch of project types.

-- Alex Hoffman
expressapp.blogspot.com

Hi Alex

I'm slowly getting over my shock ;)  I'm looking at how XPO works a bit more and it does indeed look very good, if a little "quirky" here and there!  I'm also sure that you are right that it is indeed a productive tool.  I've been looking into [Association] and have noticed that it kindly handles the synchronisation of the reverse link for me, which is nice of it.  I think loosing the ability to have a one-way association is a small price.

How do you handle cases where a number of classes have associations to a single type?  Let's say that I have Customer.Addresses and Employee.Addresses links, both of which link to my Address class.  Would you subclass Address to CustomerAddress and EmployeeAddress, or is there a more elegant way of handling that scenario?

Cheers

Sean

As an 'aside' (if you don't mind), what is the downside of the 2 way relationship? In other words, why would you not want to associate a Customer with the Orders?

For mutiple associations I have been using both subclassing and multiple associations (Employee-Address, Customer-Address, Supplier-Address, etc).

Bill

@Bill:  In the case of the Customer-Orders, I would indeed want to have the relationship two-way as I would want to navigate from the Order to its Customer.  The sole reason I want a one-way relationship is driven by Occam's Razor  - I only want to include the relationships my design requires.  If the reverse relationship is not required, it pollutes my model. 

I can see that the solution of having redundant links (Employee-Address, Customer-Address, Supplier-Address) or subclasses that are only there to support my ORM tool would work but are not ideal from the design perspective.  That said, I think that XPO does bring more to the table than it takes away!

Maybe I'll put in a change request :)

Cheers

Sean

@Sean: in this case are you saying that your system would not need to navigate from Customers to their orders?  drew..

@Drew: no, I don't have a system with customers and orders in it - that's just an example!

P.S. Love the pic - is that a Springer?

drew..:

@Sean: in this case are you saying that your system would not need to navigate from Customers to their orders?  drew..

 Did I mis read it I thought the example was that you would map from Customer to the collection of Orders but not start with the order and map back to the customer - this "might" make sense since a customer making an enquiry would cause the system operator to always start at the customer and follow through to the orders belonging to that customer. If you consider the "under the bonnet" implementation of this and how you would handle this without XPO you might have a CustomerOrders table which contains the customer ID and the Order ID to link the two. Alternatively you could store the Customer ID in the orders table. Either implementation would allow a two way "association" between the records. How would a one-way association be implemented (without XPO)?

Of more interest (to me) was the question of various Contact types that MAY be implemented as different Classes all linking to one Address type - you can take this a step further and say have one Contact object which maps to an Address object (or objects) when in software you then need to filter the contacts depending upon a ContactType property easy enough in an XPO application but how do you handle this in an XAF application short of going back to having the SupplierContact, Supplier Address, ManufacturerContact, ManufacturerAddress etc classes which has got to be easier to implement but the desire to consolidate these can be attractive on a logical level.

Hi Steve

There is no way of implementing a one-way association in the database as you can always navigate either way.  In the object model associations are always one-way and you need to explicitly implement both to have a two-way navigability (Customer.Orders & Order.Customer).

Your scenario makes some sense of the example of not having a backward customer link from the order, but I was only meaning to use it as an example to talk about XPO...I don't really have a system with customers and orders in it!

Cheers

Sean

hey Sean, that is Kinga, one of my border collies, swimming in his favourite lake here in BC, CA. You can see Kinga on youtube if you search for poolerdude..he and his little girlfriend have some neat vids.

One area within xaf's future that may be of interest is the whole Domain Component research.. check out the blogs. It all started long ago when we xaf'rs were discussing this whole scenario of reusable domains and realizing how tough it was.

Hi Drew - great vids & a nice pooch too!  Agile, intelligent and well trained.  I have a Staffordshire Bull Terrier - lovely dog, but almost the opposite to all the aforementioned!! 

I have looked at some of the DC stuff going along with XAF and it looks interesting.  I may well take a serious look at XAF after I've completed my current project (which is 90% likely to be a leap into XPO!).

Looks like XPO is going to be sticking with two-way assocations only in the object model for now!  Response from DevExpress to my request is here.