C Sharp Object 在另一个类中仅创建和引用 1 个对象
我需要在商店场景应用程序中实现 1..* 和 1..1 关系。(类:Member、Order、OrderLine、Product、Program、User) 我如何处理只有 1 个订单的 1 个用户许多 OrderLines(最好使用列表结构?
这是我的用户类:
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}", fName, lName);
return myUser;
}
// Properties
public string fName
{
get
{
return ffName;
}
set
{
ffName = value;
}
}
public string lName
{
get
{
return llName;
}
set
{
llName = value;
}
}
}
}
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}", fName, lName);
return myUser;
}
// Properties
public string fName
{
get
{
return ffName;
}
set
{
ffName = value;
}
}
public string lName
{
get
{
return llName;
}
set
{
llName = value;
}
}
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您可以有一个 Order 类和一个 OrderLine 类。 Order 类将有一个 OrderLines 列表,而 User 类可以有一个 Order 成员。
像这样的东西:
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:
您必须将
Order
和OrderLine
类实现为:然后将
Order
类添加到您的用户类中。You have to implement the
Order
and theOrderLine
class as:Then add the
Order
class to your user class.编辑:删除尖刻和态度:)
首先你需要一个命令(暗示你需要为此上课)。现在需要将订单附加到用户。因此添加一个 User 类型的字段。这样就可以处理一个用户的一个订单。 (请注意,一个用户可以下多个订单)
所以现在您的订单缺少行。添加另一个成员变量,它是线类型列表。现在,您需要在订单中添加添加、删除和查询订单行的方法。
编辑:提出了“添加字段”的含义的问题。添加字段意味着添加属性或私有成员。当你这样做时,你正在做组合的技术术语。组合通常被解释为“具有”关系。因此,订单“有一个用户”和“有一个订单行列表”
示例
编辑:将成员类更改为用户类
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"
Example
EDIT: Changed Member class to User class
您最近的评论澄清了您的问题:
所以,让我们来谈谈关系的类型。
关系类型
关系类型并不涉及系统中实体的绝对数量。他们只是谈论与其他实体相关的实体数量。
1:1 关系
这意味着两种实体类型必须成对存在。如果存在一个 A 类型实体,则只能存在一个 B 类型实体。例如,您的
用户
和订单
。没有用户
就不可能存在订单,并且用户
只能有一个订单
。这并不意味着只有一个用户
- 可能有 42 个用户。这只是意味着,如果存在Order
,则User
也必须存在,并且User
只能有一个Order.
有一个严格的和不太严格的版本。从技术上讲,我只是描述了 1:{0 或 1} 关系。在真正的 1:1 关系中,如果
用户
存在,您要求订单也存在。如果另一个不存在,则两者都不可能存在。然而,在谈论关系数据库时,这一约束通常会被放松(但仅限于一个方向 - 在这种情况下,如果没有User
,您仍然无法拥有Order
)。您可以使用如下代码来建模这种关系:
请注意,仅支持
User
的一个Order
有点奇怪。将其设为1:*
更有意义。但如果这是您的作业的要求,那么这就是您对其进行建模的方式。1:* 关系
这类似于 1:1 关系。但它放宽了一些限制,因此如果存在 A 类型的实体,则可以存在任意数量(包括零)的 B 类型实体。该示例是
Order
和OrderLine
。同样,对于任一实体类型的存在数量没有限制。 系统中可能有 57 个订单。如果没有Order
,就不可能有OrderLine
,并且每个Order
可能有多个OrderLine
。您可以使用如下代码来建模这种关系:
在代码中强制执行关系概念
我不能代表您的作业,因此请确保您根据您的作业要求支持我在这里所说的内容。
您不应该尝试在代码中强制诸如此类的基本关系概念。数据库在这方面做得更好,有更好的(声明性)语言来描述关系,并且将成为系统的最终数据源。
相反,您应该只创建一个遵循关系的软模型(如上面的代码示例所示),并让数据库对这些约束进行真正的监管。
示例:
Order
类型的构造,也不应要求存在User
来构造Order
(作为代码实体)。Order
才能创建OrderLine
(作为代码实体)。尝试在代码中加入这些限制不会给你带来任何好处。当您将实体持久保存到数据库时,数据库将为您确保这些关系(假设您已正确设置它,您将学习如何做到这一点)。您的错误将被发现,并且您将很快养成避免此类错误的习惯。
试图在代码中加入这些限制会伤害你。编写程序将会更加困难,为代码编写单元测试也会更加困难。
例如,考虑比较
OrderLine
值的算法或测试。也许您希望将其与假设OrderLine
进行比较。如果您的代码中存在关系限制,则还必须创建假设的Order
和User
。您还会将假设的User
和Order
与真实情况进行比较吗?如果您的算法不应该关心它源自哪个User
或Order
怎么办?如果您不打算比较它们,为什么要费心去创建它们呢?所以:不用担心。对您的关系进行软建模,以便轻松在对象之间导航,并让数据库为您进行严格的关系验证。
Your most recent comment cleared up your question:
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
andOrder
. An order can't exist without aUser
, and aUser
can only have oneOrder
. This doesn't mean there is only oneUser
- there could be 42 users. This just means that if anOrder
exists, aUser
must also exist, and that theUser
can only have oneOrder
.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 theUser
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 anOrder
without aUser
).You can model this relationship with code like this:
Note that it is a bit weird to only support only one
Order
for aUser
. It makes more sense to make it1:*
. 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
andOrderLine
. 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 anOrderLine
without anOrder
, and there could be multipleOrderLine
s perOrder
.You can model this relationship with code like this:
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:
Order
types in code, and you shouldn't require aUser
to exist to construct anOrder
(as code entities).Order
to exist to create anOrderLine
(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 hypotheticalOrderLine
. If you had relational restrictions in place in your code, you'd also have to create a hypotheticalOrder
andUser
. Would you also compare the hypotheticalUser
andOrder
to the real ones? What if your algorithm shouldn't care whatUser
orOrder
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.