Aggregation in C#

[Guest]

In C#, how would people implement a relationship between Customer class and
Request class, considering a customer may have 0-n requests and a request
must belong to 1 and only 1 customer...?

Would about the following options?

OPTION 1
--------------------------
public class Customer()
{ private int CustomerID;
private string CustomerName;
}

public class Request()
{ private int IdRequest;
private datetime OrderDate;
private Customer Customer; ---Notice here I reference Customer class
}

OPTION 2
--------------------------
public class Customer()
{ private int CustomerID;
private string CustomerName;
private Request Request; ---Notice here I reference Request class
}

public class Request()
{ private int IdRequest;
private datetime OrderDate;
}

Besides, both ways above dont allow me to work with a list of requests
related to a customer, right?

Could someone give me some light on it? Im kind of lost...

Tanks

 

[Markus]

OPTION 1

--------------------------
public class Customer()
{ private int CustomerID;
private string CustomerName;
}

public class Request()
{ private int IdRequest;
private datetime OrderDate;
private Customer Customer; ---Notice here I reference Customer class
}

Works fine, if you only need to know the customer from a Request object.

OPTION 2
--------------------------
public class Customer()
{ private int CustomerID;
private string CustomerName;
private Request Request; ---Notice here I reference Request class
}

public class Request()
{ private int IdRequest;
private datetime OrderDate;
}

Does not work. You know, what Request belongs to a Customer, but it is
limited to one Request.


I would recommend Option 2 with a list or array. Something like:
private IList<Request> requests; // using generics on .NET 2.0
private IList requests; // normal list
private Request[] requests; // array

Could someone give me some light on it? Im kind of lost...

hth
Markus

 

[Joanna Carter [TeamB]]

"Bruce One" <[email protected]> a écrit dans le message de (e-mail address removed)...

| In C#, how would people implement a relationship between Customer class
and
| Request class, considering a customer may have 0-n requests and a request
| must belong to 1 and only 1 customer...?

Aggregation is a term that tends to be used for two different types of
relationship: true aggregation or composition. The main difference is one of
ownership.

Composition implies that one object owns a list of other objects, the owned
objects can only be created and destroyed by the owner, their lifetime is
tied to the lifetime of the owner.

A typical example of Composition is a master/detail relationship like Sales
Order or Invoice. For this scenario, it is important that the list of
"details" included in the composite class is a read-only list and that any
additions or removals from that list can only be made through the "master"
object.

public class ReadOnlyList<itemT> : IEnumerable<itemT>
{
private List<itemT> items = new List<itemT>();

public itemT this[int index]
{
get { return items[index]; }
}

public IEnumerator<itemT> GetEnumerator()
{
return items.GetEnumerator();
}
}

public class Invoice
{
public class Line
{
internal Line() // non-public constructor to prevent anything other
// than Invoice from creating instances
{
}

// ...
}

private ReadonlyList<Line> lines = new ReadOnlyList<Line>();

public ReadonlyList<Line> Lines
{
get { return lines; }
}

public Line Add()
{
Line newLine = new Line();
lines.Add(newLine);
return newLine;
}

public void RemoveAt(int index)
{
if (index < 0 || index >= lines.Count)
throw new Exception("Index out of range");
lines.RemoveAt(line);
}

public void Remove(Line line)
{
if (!lines.Contains(line))
throw new Exception("Line does not belong to this Invoice");
lines.Remove(line);
}
}

This construct means that you have to ask the Invoice to create a Line
rather than creating them externally and then adding them.

{
Invoice inv = new Invoice();

Invoice.Line line = inv.Add();
line.Qty = 1;
// etc
}

Aggregation implies that one object can have a list of other objects but
that that the items in that list have their own lives and can be created and
destroyed in their own contexts separately from the containing object.

In your example, I am assumling that Requests can exist separately from
Customers :

public class Request()
{
private int IdRequest;
private datetime OrderDate;
}

public class Customer()
{
private int CustomerID;
private string CustomerName;
private List<Request> Requests = new List<Request>();
}

Note that the full list class is available, so you can use code like this :

{
Customer cust = new Customer();

Request req = new Request()

cust.Requests.Add(req);

...
}

Joanna

 

[Michael Moreno]

Hi,

I have a very simple way of doing this: adding an association class as
shown below.

public class Customer()
{ private int CustomerID;
private string CustomerName;
}

public class Request()
{ private int IdRequest;
private datetime OrderDate;
}

public class CustomerRequest
{
private Customer customer;
private ArrayList requests; // or Generics if you use 2.0
}

That way I fully understand how things are related and each object is
kept independant.

 

[Joanna Carter [TeamB]]

"Michael Moreno" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...

| I have a very simple way of doing this: adding an association class as
| shown below.

| public class CustomerRequest
| {
| private Customer customer;
| private ArrayList requests; // or Generics if you use 2.0
| }
|
| That way I fully understand how things are related and each object is
| kept independant.

Ah, the old OO link-table ploy )

Seriously though, this is an often overlooked construct that solves a
problem that *shouldn't* always be done by adding a field/list of one class
in the other.

I have actually defined classes like SalesOrder as an association between a
Customer and a collection of OrderLines.

Joanna

 

[Michael Moreno]

Ah, the old OO link-table ploy )

Encapsulation does the job indeed.
Have you quit the Delphi world?

 

[Joanna Carter [TeamB]]

"Michael Moreno" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...

| Have you quit the Delphi world?

For the while, until someone wants my services to design Delphi apps. At the
moment I am rather enjoying working in C#, especially 2.0; I'm just in the
middle of a big redesign/port of a massive Delphi vertical market
application to .NET using VS and loving every moment of it

The framework library is *so* massive though, it has caused me, on several
occasions, to scrap my own code in favour of easier to use solutions in the
framework.

My own MVP framework has evolved significantly to a very mature, very
capable means of removing all non design code from visual forms that is a
joy to use; especially because .NET data-awareness is no longer restricted
to just TDataset derivatives

Joanna

 

[Susan Mackay]

Except that this implements a n-n relationship between Customer and Request,
not 1-n.

Not that this is bad - its just not what the original poster is looking for.