对基库的思考
The new Domain Components framework will let developers create reusable domain components. Obviously, we should supply our variant of the domain component library. Our library should be full enough to let XAF developers start fast, and to provide a common well-established base for domain component developers. At the same time, it should be flexible enough to let developers replace or extend the parts that they don’t like.
新的领域构件框架将让开发者建立可重用的领域构件。显然，我们应当提供我们的领域构件库的变体。我们的库应该足够让XAF开发者快速开始，为领域构件开发者提供一个通用的完善的基础。同时，也应当足够灵活的让开发者更换或扩展他们不适用的部分。
I think, in the end, we will have our domain component library derived in two parts – very specific base components, which will be reused across all other components, and common domain components, which can be replaced or extended as required. Let me illustrate this approach.
我认为，最终，我们将有我们的领域构件库分两部分-非常具体的基组件，将重用其他所有组件，常用领域构件，能被替换或者按需扩展。让我们举例说明这种方法。
Nearly every application needs information about a person. It can be just user information, or more detailed information on a customer, or very detailed information on a legal person. Obviously, there should be a base component Person, which will be referenced and reused by third-party domain components, and a real Person component, which contains more detailed information.
几乎每个应用程序都需要一个Person信息。它能成为用户信息或者更详细的客户信息，或非常详细的法人信息。显然，应当是一个基组件Person,这就引用和重用第三方领域构件，一个真正的Person组件，包含更详细的信息。
Components that reference the base Person don't need much information on it. So, it may contain a FullName and ShortName, and, in rare cases, Birthday and Gender:
引用该组件基础上的Person不需要更多信息。因此，它可能包括一个FullName 和 ShortName,偶尔包括Birthday 和 性别：
public interface IPersonRef {
string FullName { get; }
string ShortName { get; }
DateTime? Birthday { get; }
Gender Gender { get; set; }
}
A real Person component may have more properties: FirstName, MiddleName and LastName, or GivenName, Surname and FatherName (depends on the culture). We should provide the Person that is sufficient in common cases – like this
一个真正的Person构件可能有更多属性：FirstName, MiddleName 和 LastName, 或者 GivenName, Surname 和 FatherName(取决于文化)。我们应当提供足够的Person在普通情况下，像这样：
|
[DomainComponent] |
|
public interface IPerson : IPersonRef { |
|
string FirstName { get; set; } |
|
string MiddleName { get; set; } |
|
string LastName { get; set; } |
|
} |
You can use your own IPersonRef descendant in your application, instead of the IPerson. In this instance, all domain components that depend on the IPersonRef interface will work. For this purpose, we will provide a way to tell the system that "in this application the IPersonRef should be resolved into the RomanEremin.DC.General.IRussianPerson component".
在你的应用程序中你能用你自己的IpersonRef后代，替代IPerson.在这样情况下，所有的领域构件都依赖IpersonRef接口工作。为此，我提供一个方法告诉，在这个应用程序中的IPersonRef应当被分解成RomanFremin.DC.General.IrussianPerson组件。
Now, we are at the genesis of creating a base domain component library, and considering an approach to implement a useful one. I think we should start writing a real-world application (this has been requested for some time). While writing, we will get core, common and application-specific components that can be included in our component library.
现在，我们在创建一个基本领域构件库的起源，考虑实现一种有用的方法。我认为我们应当开始写一个真实的应用程序(在一段时间内的需求)。在写，我们将得到的核心，通用和特殊应用构件，包括在我们的构件库中。
What application should we write? I'm thinking of a generic CRM application. Most of us are intuitively familiar with applications of this type, so we won’t need to explain much, and most of us will be able to use it.
应当写什么应用程序？我写了一个通用的CRM应用程序。我们多少人都熟悉这种类型的应用程序，因此，我不需要解释更多，我们大部分都能够使用它。
欢迎转载，转载请注明出处：http://www.cnblogs.com/Tonyyang/
欢迎转载，转载请注明出处：http://www.cnblogs.com/Tonyyang/
