C Sharp Object creating and referencing only 1 object in another class

I need to implement 1..* and 1..1 relationships in a store scenario application.(Classes: Member, Order, OrderLine, Product, Program, User) How do i go about a 1 user only having 1 Order that can have many OrderLines (preferably using a List structure?

This is my User class:

namespace ConsoleApplication1
{
    public class User
    {

        private string ffName;
        private string llName;
        private int id = 0;

        //Constructor
        public User(string firstName, string lastName)
        {
            fName = firstName;
            lName = lastName;
        }
        public User() {}

        //Overrides
        public override bool Equals(object obj)
        {
            return obj.ToString() == this.ToString();
        }
        public override int GetHashCode()
        {
            return this.ToString().GetHashCode();
        }
        public override string ToString()
        {
            string myUser;
            myUser = string.Format("First Name: {0}; Last Name: {1}",开发者_如何学Python fName, lName);
            return myUser;     
        }

        // Properties
        public string fName
        {
            get
            {
                return ffName;
            }
            set
            {
                ffName = value;
            }
        }
        public string lName
        {
            get
            {
                return llName;
            }
            set
            {
                llName = value;
            }
        } 
    }
}

You can have an Order class and an OrderLine class. The Order class will have a List of OrderLines and the User class can have a Order member.

Something like:

public class User
    {

        private string ffName;
        private string llName;
        private int id = 0;
        private Order order = null;

        //Constructor
        public User(string firstName, string lastName)
        {
            fName = firstName;
            lName = lastName;
        }
...
}

public class Order
{
 List<OrderLine> orderLines = null;
}

public class OrderLine
{
}

You have to implement the Order and the OrderLine class as:

class OrderLine
{
      //some code
}


class Order
{
     List<OrderLine> lstOrderLine;

     //some code
}

Then add the Order class to your user class.

Edit: Removed snarkyness and attitude :)

First you need an order (hint you are going to need a class for that). Now the order needs to be attched to a user. So add a field of type User. That takes care of one order one user. (Note that a user can make more than one order)

So now you order is missing lines. Add another member variable that is a list of line types. Now in your order you need to add methods to add, remove and query order lines.

Edit: The question was raised what was meant by "add a field". Add a field means add a property or private member. When you are doing this you are doing the technical term of composition. Composition is commonly explained as a "has a" relationship. So an order "has a user" and "has a list of order lines"

Class User()
{
    public string firstName { get; set; }
    public string lastName {get; set; }
    public int id { get; set;}
}

Class OrderLine()
{

}

Class Order()
{
    private List<OrderLine> orderLines;
    public User submitter { get; set;}

    public Order()
    {
         orderLines = new List<OrderLine>();
    }

    public void AddOrderLine(OrderLine newOrderLine)
    {
         this.orderLines.Add(newOrderLine);
    }

    public IList<OrderLine> GetOrderLines()
    { 
         return this.orderLines;
    }
}

Example

User customer1 = new User();
// Initialize customer1 values...
Order someOrder = new Order();
someOrder.submitter = customer1;
someOrder.AddOrderLine(new OrderLine());

EDIT: Changed Member class to User class

Your most recent comment cleared up your question:

Its not hard to create each one i just dont understand how to get the relationship to work with 1..* or 1..1. If i create an Order i can always create another order

So, let's talk about the types of relationships.

Relationship types

Relationship types don't talk about absolute numbers of entities in the system. They just talk about numbers of entities in relation to other entities.

1:1 Relationship

This means that the two entity types must exist in pairs. If one entity of type A exists, then only one entity of type B can exist. For example, your User and Order. An order can't exist without a User, and a User can only have one Order. This doesn't mean there is only one User - there could be 42 users. This just means that if an Order exists, a User must also exist, and that the User can only have one Order.

There is a strict and less strict version of this. Technically, I just described something like a 1:{0 or 1} relationship. In a real 1:1 relationship you would require that the Order exists if the User exists. Neither could exist if the other didn't exist. However this constraint is usually relaxed when talking about relational databases (but only in one direction - in this case you still can't have an Order without a User).

You can model this relationship with code like this:

public class User
{
    public Order Order { get; set; }
}

public class Order
{
    // You could put a reference here back to the User if you want...
}

Note that it is a bit weird to only support only one Order for a User. It makes more sense to make it 1:*. But if that is a requirement of your assignment, then this is how you'd model it.

1:* Relationship

This is similar to the 1:1 relationship. But it relaxes some of the restrictions so that if an entity of type A exists, then any number (including zero) of type B can exist. The example is the Order and OrderLine. Again, there is no restriction on how many of either entity type exist. There could be 57 orders in the system. You just can't have an OrderLine without an Order, and there could be multiple OrderLines per Order.

You can model this relationship with code like this:

public class Order
{
    public List<OrderLine> OrderLines { get; set; }
}

public class OrderLine
{
    // You could put a reference here back to the Order if you want...
}

Enforcing relational concepts in code

I can't speak for your assignment, so make sure you back up what I am saying here against what your assignment requires.

You should not try to enforce basic relational concepts like these in code. The database is better at it, has better (declarative) language to describe the relationships, and is going to be your ultimate source of data for the system.

Instead, you should just do a soft model that follows the relationships (as the code samples above do), and let the database do the real policing of those constraints.

Examples:

• You should not try to restrict construction of Order types in code, and you shouldn't require a User to exist to construct an Order (as code entities).
• You should not require an Order to exist to create an OrderLine (as code entities).

Trying to put these sorts of restrictions in code buys you nothing. When you persist the entities to the database, the database will ensure these relationships for you (assuming you've set it up correctly, which you will learn to do). Your error will be caught, and you'll learn habits that avoid these types of errors very quickly.

Trying to put these sorts of restrictions in code hurts you. It will be harder to write your program, and it will be harder to write unit tests for your code.

For example, consider an algorithm or test that compares OrderLine values. Maybe you want it to compare to a hypothetical OrderLine. If you had relational restrictions in place in your code, you'd also have to create a hypothetical Order and User. Would you also compare the hypothetical User and Order to the real ones? What if your algorithm shouldn't care what User or Order it originated from? If you're not going to compare them, why bother creating them to begin with?

So: Don't worry about it. Softly model your relationships so that it is easy to navigate between your objects, and let the database do your strict relationship validations for you.