DC中的关联
This post is one in a series about our work on Domain Components (DC) framework and related component libraries. I’m just describing what we are working on, what problems we are facing and what results we've got so far.
这篇文章是系列博客之一，关于我们对DC框架工作情况，有关构件库。我只是描述了我们正在努力的工作，遇到的问题，以及目前的工作进展。
In my previous post I was looking at INote interface:
我以前帖子上的Inote接口：
|
|
|
|
1 |
public interface INote { |
|
2 |
string Text { get; set; } |
|
3 |
IItemWithNotes Owner { get; set; } |
|
4 |
} |
There is another thing I don’t like in this code: I don’t want the INote interface to know about the IItemWithNotes interface. But currently in XPO I have to define back references. Why? Let me explain the problem. Look at the class structure below:
另外我不喜欢这个代码：我不想Inote接口知道ItemWithNotes接口。但目前在XPO中我不得不定义向后引用。为什么？看下面类结构
|
public class Developer : XPObject { |
|
private string name; |
|
public Developer(Session session) : base(session) { } |
|
public string Name { |
|
get { return name; } |
|
set { SetPropertyValue("Name", ref name, value); } |
|
} |
|
[Association] |
|
public XPCollection Notes { get { return GetCollection("Notes"); } } |
|
} |
|
public class Note : XPObject { |
|
private string text; |
|
public Note(Session session) : base(session) { } |
|
public string Text { |
|
get { return text; } |
|
set { SetPropertyValue("Text", ref text, value); } |
|
} |
These classes won't work correctly in XPO. In a relational database, a One-to-Many relation is performed by adding a foreign key to the table. For the classes above, you would create a table structure where the Note table has the foreign key column that stores a Developer's OID:
当前，在XPO中，这个类不能工作。在一个关系数据库中，一对多关系，是给一个表添加一个外键。对于上面的类，你应当在Note表中增加一个外键存储Developer的ID:
To retrieve the Notes that are associated with a particular Developer ID, you would write an SQL query like this: "select * from Note where Developer = <developer id>". XPO generates all queries for you. To generate the query I showed to you, XPO requires that the Note class has a property mapped to a foreign key column. In other words, the Note class should look like this:
要检索与某个开发者相关的Note,你应当写这样的SQL查询："select * from Note where Developer = <developer id>"。XPO为你生成所有查询。要让XPO生成查询，XPO需要为Note类映射一个外键列。换句话说，这个Note类应当是这样：
|
public class Note : XPObject { private string text; private Developer developer; public Note(Session session) : base(session) { } public string Text { get { return text; } set { SetPropertyValue("Text", ref text, value); } } [Association] public Developer Developer { get { return developer; } set { SetPropertyValue("Developer", ref developer, value); } } } |
In this instance, XPO will find both ends of the Developer-Note association and create all necessary constraints and foreign keys.
在这个示例中，XPO将找到Developer-Note两端，建立所有所需的约束和外键。
But I’m working on the Domain Component library. My goal is to provide a framework for domain components – a puzzle's independent pieces. While writing the Note component, I don’t want it to know how anybody uses it. For instance, it can be used in the following entity (I know this is not a good design, but I still think it should be possible to do so):
但我的任务的目标是提高一个领域构件框架—一个难题，独立产品。虽然写了Note构件，我不希望它知道何人使用它。例如，他能用在下列实体（我知道这样不好设计，但我扔想尽力实现它）。
|
public interface IFullOfNotes { IList<INote> PublicNotes { get; } IList<INote> PrivateNotes { get; } IList<INote> DraftNotes { get; } } |
To map the IFullOfNotes to the database, Note table should have three foreign keys. If the XpoBuilder can generate back-reference (foreign key) properties automatically, our DC components will be much more flexible.
要映射IfullOfNotes到数据库中，Note表应当有三个外键。如果XpoBuilder能自动生成外键属性，我们的构件将更加灵活。
So, I want to write the following code in my Notes library:
因此，我希望写下面代码子我的Notes库：
|
public interface IItemWithNotes { |
|
IList<INote> Notes { get; } |
|
} |
|
|
|
public interface INote { |
|
string Text { get; set; } |
|
} |
I've added tests that express my desire. And again… I'm waiting for an answer from the XPO team. Stay tuned.
我已经添加了测试，表达我的愿望。再一次...我在等待从XPO小组的解答。敬请关注。
欢迎转载，转载请注明出处：http://www.cnblogs.com/Tonyyang/
欢迎转载，转载请注明出处：http://www.cnblogs.com/Tonyyang/
