blocks|key|2993909|text|解决这个问题的一种方法是使用元层，或者反射，或者两者都使用。此外，您将需要提供一个自定义应用程序，它将允许用户修改您的业务逻辑层。这样的元层并不真正适合您的分层体系结构-它更像是与现有体系结构正交的层，尽管运行的应用程序可能需要引用它，至少在初始化时。这种类型的工具可能是搞砸人类已知的生产应用程序的最快方法之一，因此您必须：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2993910|2993911|确保对此编辑器的访问权限仅限于对系统具有高级别权限的人员(例如，在将他们正在测试的任何更改放到生产系统之前，为要测试的客户修改设置一个沙箱区域。|ordered-list-item|2993912|一种"OOPS“工具，他们可以通过该工具将其生产系统恢复为您提供的初始默认设置或更改前的最后一个版本。|2993913|您的元层必须严格指定，以便严格定义活动范围--|2993914|)|2993915|您的元层中将包含对象，如业务对象、方法、属性和事件，如添加业务对象、调用方法等。|2993916|web上有大量关于元编程的信息，但我会从Program+Design+Vol+2的模式语言或任何与Kent或Coplien相关或源自Kent或Coplien的WWW资源开始。|2993917|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

A way of approaching this is to use a meta-layer, or reflection, or both. In addition you will need to provide a customisation application which will allow modification, by the users, of your business logic layer. Such a meta-layer does not really fit in your layered architecture - it is more like a layer orthoganal to your existing architecture, though the running application will probably need to refer to it, at least on initialisation. This type of facility is probably one of the fastest ways of screwing up the production application known to man, so you must:

<ol>
<li>Ensure that the access to this editor is limited to people with a high level of rights on the system (eg administrator).</li>
<li>Provide a sandbox area for the customer modifications to be tested before any changes they are testing are put on the production system.</li>
<li>An "OOPS" facility whereby they can revert their production system to either your provided initial default, or to the last revision before the change.</li>
<li>Your meta-layer must be very tightly specified so that the range of activities is closely defined - George Orwell's "What is not specifically allowed, is forbidden."</li>
</ol>

Your meta-layer will have objects in it such as Business Object, Method, Property and events such as Add Business Object, Call Method etc.

There is a wealth of information about meta-programming available on the web, but I would start with Pattern Languages of Program Design Vol 2 or any of the WWW resources related to, or emanating from Kent or Coplien.

blocks|key|2993938|text|我们开发了一个SDK，它可以做这样的事情。我们选择COM作为我们的核心，因为我们使用它比使用低级.NET要舒服得多，但毫无疑问，您可以用.NET原生地完成所有这些工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2993939|基本的体系结构是这样的:类型在COM类型库中描述。所有类型都派生自名为Object的根类型。COM实现此根对象类型，并通过IDispatch提供对派生类型属性的常规访问。这个动态链接库被包装在一个.NET+PIA程序集中，因为我们预期大多数开发人员会更喜欢在.NET中工作。|2993940|我们的产品是版本1，我们还没有实现方法-在这个版本中，业务逻辑必须编码到客户端应用程序中。但我们的总体愿景是，方法将由开发人员用他选择的语言编写，编译成.NET程序集或COM+DLL(也可能是Java语言)，并通过IDispatch公开。然后，根对象类型中的相同IDispatch实现可以调用它们。|2993941|如果您预期大多数自定义业务逻辑将是验证(例如检查重复的机箱号)，那么您可以在根对象类型上实现一些常规事件(假设您使用的方式与我们类似)。每当属性更新时，我们的对象类型都会触发一个事件，我想这可以通过一个验证方法来增强，如果定义了一个验证方法，它就会被自动调用。|2993942|创建这样的通用系统需要大量的工作，但回报是在SDK之上的应用程序开发非常快。|2993943|您说您的客户应该能够添加自定义属性并自己实现业务逻辑，而无需编程。如果您的系统还实现了基于类型的数据存储(我们的实现)，那么客户可以通过编辑模型来添加属性，而无需编程(我们提供了GUI模型编辑器)。您甚至可以提供一个通用的用户应用程序，该应用程序根据类型动态地显示适当的数据输入控件，这样您的客户就可以捕获自定义数据，而无需额外的编程。(我们提供了一个通用的客户端应用程序，但它更像是一个开发人员工具，而不是一个可行的最终用户应用程序。)我不明白你怎么能允许你的客户在没有编程的情况下实现自定义逻辑……除非您想提供某种拖放式GUI工作流构建器...当然这是一项艰巨的任务。|2993944|我们不打算让商业用户做任何这样的事情。在我们的开发模型中，所有定制都是由开发人员完成的，但不一定是昂贵的-我们的愿景的一部分是允许经验较少的开发人员生成健壮的业务应用程序。|2993945|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

We develop an SDK that does something like this. We chose COM for our core because we were far more comfortable with it than with low-level .NET, but no doubt you could do it all natively in .NET.

The basic architecture is something like this: Types are described in a COM type library. All types derive from a root type called Object. A COM DLL implements this root Object type and provides generic access to derived types' properties via IDispatch. This DLL is wrapped in a .NET PIA assembly because we anticipate that most developers will prefer to work in .NET. The Object type has a factory method to create objects of any type in the model.

Our product is at version 1 and we haven't implemented methods yet - in this version business logic must be coded into the client application. But our general vision is that methods will be written by the developer in his language of choice, compiled to .NET assemblies or COM DLLs (and maybe Java too) and exposed via IDispatch. Then the same IDispatch implementation in our root Object type can call them.

If you anticipate that most of the custom business logic will be validation (such as checking for duplicate chassis numbers) then you could implement some general events on your root Object type (assuming you did it something like the way we do.) Our Object type fires an event whenever a property is updated, and I suppose this could be augmented by a validation method that gets called automatically if one is defined.

It takes a lot of work to create a generic system like this, but the payoff is that application development on top of the SDK is very quick.

You say that your customers should be able to add custom properties and implement business logic themselves "without programming". If your system also implements data storage based on the types (ours does) then the customer could add properties without programming, by editing the model (we provide a GUI model editor.) You could even provide a generic user application that dynamically presents the appropriate data-entry controls depending on the types, so your customers could capture custom data without additional programming. (We provide a generic client application but it's more a developer tool than a viable end-user application.) I don't see how you could allow your customers to implement custom logic without programming... unless you want to provide some kind of drag-n-drop GUI workflow builder... surely a huge task.

We don't envisage business users doing any of this stuff. In our development model all customisation is done by a developer, but not necessarily an expensive one - part of our vision is to allow less experienced developers produce robust business applications.

blocks|key|282257|text|我觉得有两种方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|282258|1)如果不同的客户端属于相同的域(如制造/金融)，那么最好以这样的方式设计对象:+BaseObject应该具有非常常见的属性，而其他属性可以在不同的客户端之间作为键值对而变化。在此基础上，尝试实现像IBM+ILog(http://www-01.ibm.com/software/integration/business-rule-management/rulesnet-family/about/)这样的规则引擎。|offset|length|282259|2)预测模型标记语言(http://en.wikipedia.org/wiki/PMML)|282260|entityMap|0|LINK|mutability|MUTABLE|url|http://www-01.ibm.com/software/integration/business-rule-management/rulesnet-family/about/|1|http://en.wikipedia.org/wiki/PMML^0|0|30|2I|0|0|B|X|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

Two approaches is what I feel:

1) If different clients fall on to same domain (as Manufacturing/Finance) then it's better to design objects in such a way that BaseObject should have attributes which are very common and other's which could vary in between clients as key-value pairs. On top of it, try to implement rule engine like IBM ILog(http://www-01.ibm.com/software/integration/business-rule-management/rulesnet-family/about/).

2) Predictive Model Markup Language(http://en.wikipedia.org/wiki/PMML)

blocks|key|280170|text|这是您正在构建的Dynamic+Object+Model或Adaptive+Object+Model。当然，当客户开始添加行为和数据时，他们是在编程，因此您需要对其进行版本控制、测试、发布、命名空间/上下文和权限管理。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|280171|entityMap|0|LINK|mutability|MUTABLE|url|http://st-www.cs.illinois.edu/users/johnson/papers/dom/dynamicobjectmodel.pdf|1|http://adaptiveobjectmodel.com/^0|8|K|0|T|L|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

That's a <a href="http://st-www.cs.illinois.edu/users/johnson/papers/dom/dynamicobjectmodel.pdf" rel="nofollow">Dynamic Object Model</a> or <a href="http://adaptiveobjectmodel.com/" rel="nofollow">Adaptive Object Model</a> you're building. And of course, when customers start adding behaviour and data, they are programming, so you need to have version control, tests, release, namespace/context and rights management for that.

blocks|key|3207640|text|这是我们最大的挑战之一，因为我们有多个客户端都使用相同的代码库，但具有广泛不同的需求。让我与你分享我们的进化故事：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3207641|我们的公司一开始只有一个客户端，当我们开始获得其他客户端时，你会开始在代码中看到类似这样的东西：|3207642|if(clientName+==+"ABC")+{
++++//+do+it+the+way+ABC+client+likes
}+else+{
++++//+do+it+the+way+most+clients+like.
}|code-block|syntax|javascript|3207643|最终，我们明智地认识到，这会使代码变得非常丑陋和难以管理。如果另一个客户希望他们的客户在一个地方表现得像ABC，而CBA在另一个地方，我们就卡住了。因此，我们转而使用具有一堆配置点的.properties文件。|3207644|if((bool)configProps.get("LastNameFirst"))+{
++++//+output+the+last+name+first
}+else+{
++++//+output+the+first+name+first
}|3207645|这是一个进步，但仍然很笨拙。“魔法弦”比比皆是。围绕各种属性没有真正的组织或文档。许多属性依赖于其他属性，不会做任何事情(甚至会破坏某些东西！)如果没有使用正确的组合。在一些迭代中，我们的大部分时间(甚至大部分时间)都花在修复错误上，因为我们已经为一个客户端“修复”了一些破坏了另一个客户端配置的东西。当我们得到一个新的客户机时，我们只需要从另一个客户机的属性文件开始，这个客户机的配置“最像”这个客户机想要的那个，然后尝试调整，直到它们看起来正确为止。|3207646|我们尝试使用各种技术来使这些配置点变得不那么笨拙，但只取得了一定的进展：|3207647|if(userDisplayConfigBean.showLastNameFirst()))+{
++++//+output+the+last+name+first
}+else+{
++++//+output+the+first+name+first
}|3207648|有几个项目可以控制这些配置。其中一个涉及到编写基于XML的视图引擎，以便我们可以更好地为每个客户端定制显示。|3207649|<client+name="ABC">
++++<field+name="last_name"+/>
++++<field+name="first_name"+/>
</client>|3207650|另一个项目涉及编写配置管理系统来整合我们的配置代码，确保每个配置点都有良好的文档记录，允许超级用户在运行时更改配置值，并允许代码验证每个更改以避免获得无效的配置值组合。|3207651|这些不同的变化无疑让每个新客户端的生活变得容易得多，但它们中的大多数都未能解决问题的根源。真正让我们受益最大的变化是，当我们不再将我们的产品视为一系列的修复，以使某些东西为另一个客户工作时，我们开始将我们的产品视为“产品”。当客户要求提供新功能时，我们开始仔细考虑以下问题：|3207652|3207653|现在或将来，还有多少其他客户端能够使用此功能？|unordered-list-item|3207654|它的实现方式是否不会减少我们的代码？|3207655|我们实现了他们所要求的不同功能，该功能仍然可以满足他们的需求，同时更适合被其他客户端重用？|3207656|3207657|3207658|在实现功能时，我们会从长远的角度来考虑。我们可以创建一个全新的表，允许任何客户端定义任意数量的自定义字段，而不是创建一个仅供一个客户端使用的新数据库字段。这将需要更多的前期工作，但我们可以允许每个客户以极大的灵活性定制自己的产品，而不需要程序员更改任何代码。|3207659|也就是说，有时如果不在复杂的规则引擎等方面投入大量的精力，就无法真正完成某些定制。当您只需要让它以一种方式为一个客户端工作，以另一种方式为另一个客户端工作时，我发现您最好的选择是使用依赖注入将程序连接到和。如果您遵循“可靠”原则来确保您的代码是模块化编写的，并且具有良好的“关注点分离”等，那么为特定客户端更改代码的特定部分的实现几乎不是那么痛苦：|offset|length|style|BOLD|3207660|public+FirstLastNameGenerator+:+INameDisplayGenerator
{
++++IPersonRepository+_personRepository;
++++public+FirstLastNameGenerator(IPersonRepository+personRepository)
++++{
++++++++_personRepository+=+personRepository;
++++}
++++public+string+GenerateDisplayNameForPerson(int+personId)
++++{
++++++++Person+person+=+_personRepository.GetById(personId);
++++++++return+person.FirstName+%2B+"+"+%2B+person.LastName;
++++}
}

public+AbcModule+:+NinjectModule
{
+++++public+override+void+Load()
+++++{
+++++++++Rebind<INameDisplayGenerator>().To<FirstLastNameGenerator>();
+++++}
}|3207661|我前面提到的其他技术增强了这种方法。例如，我没有编写AbcNameGenerator，因为其他客户可能希望在他们的程序中有类似的行为。但是使用这种方法，您可以非常容易地定义模块，以一种非常灵活和可扩展的方式覆盖特定客户端的默认设置。|CODE|3207662|因为这样的系统本质上是脆弱的，所以重点关注自动化测试也很重要:针对单个类的单元测试，确保(例如)注入绑定都正常工作的集成测试，以及确保所有内容协同工作而不会出现性能衰退的系统测试。|3207663|附言:我在整个故事中都使用了“我们”，尽管我实际上并没有在公司的大部分历史中工作。|3207664|注意:请原谅C#和Java的混合。|3207665|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|2O|5|2U|20|0|0|0|38|Q|G|0|0|2I|0|0|15|0|0|H|0^^$0|@$1|2|3|4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1W|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1X|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1Z|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|20|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|21|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|22|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|23|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|24|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|25|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|26|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|27|8|@]|9|@]|A|$]]|$1|11|3|12|5|13|7|28|8|@]|9|@]|A|$]]|$1|14|3|15|5|13|7|29|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2A|8|@]|9|@]|A|$]]|$1|18|3|-4|5|13|7|2B|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2E|8|@$1E|2F|1F|2G|1G|1H]|$1E|2H|1F|2I|1G|1H]]|9|@]|A|$]]|$1|1I|3|1J|5|F|7|2J|8|@]|9|@]|A|$G|H]]|$1|1K|3|1L|5|6|7|2K|8|@$1E|2L|1F|2M|1G|1H]|$1E|2N|1F|2O|1G|1M]]|9|@]|A|$]]|$1|1N|3|1O|5|6|7|2P|8|@$1E|2Q|1F|2R|1G|1H]]|9|@]|A|$]]|$1|1P|3|1Q|5|6|7|2S|8|@$1E|2T|1F|2U|1G|1H]]|9|@]|A|$]]|$1|1R|3|1S|5|6|7|2V|8|@$1E|2W|1F|2X|1G|1H]]|9|@]|A|$]]|$1|1T|3|-4|5|6|7|2Y|8|@]|9|@]|A|$]]]|1U|$]]

This is one of our biggest challenges, as we have multiple clients that all use the same code base, but have widely varying needs. Let me share our evolution story with you:

Our company started out with a single client, and as we began to get other clients, you'd start seeing things like this in the code:

<pre><code>if(clientName == "ABC") {
 // do it the way ABC client likes
} else {
 // do it the way most clients like.
}
</code></pre>

Eventually we got wise to the fact that this makes really ugly and unmanageable code. If another client wanted theirs to behave like ABC's in one place and CBA's in another place, we were stuck. So instead, we turned to a .properties file with a bunch of configuration points.

<pre><code>if((bool)configProps.get("LastNameFirst")) {
 // output the last name first
} else {
 // output the first name first
}
</code></pre>

This was an improvement, but still very clunky. "Magic strings" abounded. There was no real organization or documentation around the various properties. Many of the properties depended on other properties and wouldn't do anything (or would even break something!) if not used in the right combinations. Much (possibly even most) of our time in some iterations was spent fixing bugs that arose because we had "fixed" something for one client that broke another client's configuration. When we got a new client, we would just start with the properties file of another client that had the configuration "most like" the one this client wanted, and then try to tweak things until they looked right.

We tried using various techniques to get these configuration points to be less clunky, but only made moderate progress:

<pre><code>if(userDisplayConfigBean.showLastNameFirst())) {
 // output the last name first
} else {
 // output the first name first
}
</code></pre>

There were a few projects to get these configurations under control. One involved writing an XML-based view engine so that we could better customize the displays for each client.

<pre><code>&lt;client name="ABC"&gt;
 &lt;field name="last_name" /&gt;
 &lt;field name="first_name" /&gt;
&lt;/client&gt;
</code></pre>

Another project involved writing a configuration management system to consolidate our configuration code, enforce that each configuration point was well documented, allow super users to change the configuration values at run-time, and allow the code to validate each change to avoid getting an invalid combination of configuration values.

These various changes definitely made life a lot easier with each new client, but most of them failed to address the root of our problems. The change that really benefited us most was when we stopped looking at our product as a series of fixes to make something work for one more client, and we started looking at our product as a "product." When a client asked for a new feature, we started to carefully consider questions like:

<ul>
<li>How many other clients would be able to use this feature, either now or in the future?</li>
<li>Can it be implemented in a way that doesn't make our code less manageable?</li>
<li>Could we implement a different feature that what they are asking for, which would still meet their needs while being more suited to reuse by other clients?</li>
</ul>

When implementing a feature, we would take the long view. Rather than creating a new database field that would only be used by one client, we might create a whole new table which could allow any client to define any number of custom fields. It would take more work up-front, but we could allow each client to customize their own product with a great degree of flexibility, without requiring a programmer to change any code.

That said, sometimes there are certain customizations that you can't really accomplish without investing an enormous effort in complex Rules engines and so forth. When you just need to make it work one way for one client and another way for another client, I've found that your best bet is to program to interfaces and leverage dependency injection. If you follow "SOLID" principles to make sure your code is written modularly with good "separation of concerns," etc., it isn't nearly as painful to change the implementation of a particular part of your code for a particular client:

<pre><code>public FirstLastNameGenerator : INameDisplayGenerator
{
 IPersonRepository _personRepository;
 public FirstLastNameGenerator(IPersonRepository personRepository)
 {
 _personRepository = personRepository;
 }
 public string GenerateDisplayNameForPerson(int personId)
 {
 Person person = _personRepository.GetById(personId);
 return person.FirstName + " " + person.LastName;
 }
}

public AbcModule : NinjectModule
{
 public override void Load()
 {
 Rebind&lt;INameDisplayGenerator&gt;().To&lt;FirstLastNameGenerator&gt;();
 }
}
</code></pre>

This approach is enhanced by the other techniques I mentioned earlier. For example, I didn't write an <code>AbcNameGenerator</code> because maybe other clients will want similar behavior in their programs. But using this approach you can fairly easily define modules that override default settings for specific clients, in a way that is very flexible and extensible.

Because systems like this are inherently fragile, it is also important to focus heavily on automated testing: Unit tests for individual classes, integration tests to make sure (for example) that your injection bindings are all working correctly, and system tests to make sure everything works together without regressing.

PS: I use "we" throughout this story, even though I wasn't actually working at the company for much of its history.

PPS: Pardon the mixture of C# and Java.

blocks|key|2994295|text|设计一个核心模型，作为它自己的独立项目|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2994296|2994297|核心设计将包含：|2994298|在所有subprojects.|2994299|more复杂工具中工作(并可能扩展)的|unordered-list-item|2994300|类，如数据库交互(除非这些交互是特定于项目的)|2994301|是一种通用配置结构，应将其视为所有项目的标准|2994302|2994303|2994304|然后，每个客户定制的所有后续项目都被视为此核心项目的扩展。|2994305|您所描述的是任何框架的基本目的。也就是说，创建一组可以从整体中分离出来的核心功能，这样您就不必在创建的每个项目中重复开发工作。也就是说，加入一个框架，你的工作已经完成了一半。|2994306|2994307|2994308|如何跟踪所有子项目的修订历史，而不将核心包含到子项目存储库中？|2994309|幸运的是，这是一个老问题。许多软件项目，特别是linux/开源世界中的项目，大量使用外部库和插件。|2994310|事实上，git有一个专门用于将一个项目存储库作为子存储库导入另一个项目存储库的命令(保留子存储库的所有修订历史等)。实际上，您不能修改子存储库的内容，因为项目根本不会跟踪它的历史记录。|2994311|2994312|你可能会问，“如果我在一个客户的项目中开发了一个非常酷的特性，并且我想在我客户的所有项目中使用它，那该怎么办？”|2994313|只需将该功能添加到核心并在所有其他项目上运行“git子模块同步”即可。Git子模块的工作方式是，它指向子存储库的历史记录树中的特定提交。因此，当该树在上游发生更改时，您需要将这些更改拉回下游使用它们的项目。|2994314|假设您的软件是专门为管理汽车经销商(库存、销售、员工、客户、订单等)而编写的。您可以创建一个涵盖所有这些功能的核心模块，因为您的所有客户端都希望在软件中使用这些功能。|2994315|但是，你最近获得了一位新客户，他希望通过在经销商中增加在线销售来更精通技术。当然，他们的网站是由单独的web开发人员/设计师和网站管理员团队设计的，但他们想要一个web+API+(即服务层)来利用他们网站的当前基础设施。|2994316|您要做的是为客户端创建一个项目，我们将其命名为WebDealersRUs，并将核心子模块链接到存储库。|2994317|2994318|这样做的潜在好处是，一旦您开始将代码库视为可插入的部分，您就可以从一开始就将它们设计为模块化的部分，这样就可以很轻松地将它们放入项目中。|2994319|考虑上面的例子。比方说，你的客户群开始看到增加网络前台来增加销售额的好处。只需将web+API从WebDealersRU中拉出到它自己的存储库中，并将其作为一个子模块链接回来。|2994320|你所得到的是以最小的努力获得的主要回报。|2994321|2994322|当然，每个项目中总会有客户特定的部分(品牌等)。这就是为什么每个客户端都应该有一个独立的存储库，其中包含他们独特的软件版本。但这并不意味着您不能提取部件并将其泛化，以便在后续项目中重用。|2994323|虽然我从宏观层面处理这个问题，但它可以应用于代码库的较小/更具体的部分。这里的关键是您希望重用的代码需要泛化为。|2994324|OOP之所以在这里发挥作用，是因为:如果功能是在核心中实现的，但在客户端的代码中进行了扩展，那么您将使用基类并从它继承；如果功能期望返回类似类型的结果，但该功能的实现在类之间可能会有很大的差异(即，没有直接继承层次结构)，那么最好使用接口来加强这种关系。|2994325|entityMap^0|0|J|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1C|7|0|0^^$0|@$1|2|3|4|5|6|7|1W|8|@$9|1X|A|1Y|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|G|3|H|5|6|7|20|8|@]|D|@]|E|$]]|$1|I|3|J|5|6|7|21|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|22|8|@]|D|@]|E|$]]|$1|N|3|O|5|M|7|23|8|@]|D|@]|E|$]]|$1|P|3|Q|5|M|7|24|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|25|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|26|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|27|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|28|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|29|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|2A|8|@]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2B|8|@]|D|@]|E|$]]|$1|11|3|12|5|6|7|2C|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|2D|8|@]|D|@]|E|$]]|$1|15|3|-4|5|6|7|2E|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|2F|8|@]|D|@]|E|$]]|$1|18|3|19|5|6|7|2G|8|@]|D|@]|E|$]]|$1|1A|3|1B|5|6|7|2H|8|@]|D|@]|E|$]]|$1|1C|3|1D|5|6|7|2I|8|@]|D|@]|E|$]]|$1|1E|3|1F|5|6|7|2J|8|@]|D|@]|E|$]]|$1|1G|3|-4|5|6|7|2K|8|@]|D|@]|E|$]]|$1|1H|3|1I|5|6|7|2L|8|@]|D|@]|E|$]]|$1|1J|3|1K|5|6|7|2M|8|@]|D|@]|E|$]]|$1|1L|3|1M|5|6|7|2N|8|@]|D|@]|E|$]]|$1|1N|3|-4|5|6|7|2O|8|@]|D|@]|E|$]]|$1|1O|3|1P|5|6|7|2P|8|@]|D|@]|E|$]]|$1|1Q|3|1R|5|6|7|2Q|8|@$9|2R|A|2S|B|C]]|D|@]|E|$]]|$1|1S|3|1T|5|6|7|2T|8|@]|D|@]|E|$]]|$1|1U|3|-4|5|6|7|2U|8|@]|D|@]|E|$]]]|1V|$]]

Design a core model that acts as its own independent project

Here's a list of some possible basic requirements...

The core design would contain:

<ul>
<li>classes that work (and possibly be extended) in all of the subprojects.</li>
<li>more complex tools like database interactions (unless those are project specific)</li>
<li>a general configuration structure that should be considered standard across all projects</li>
</ul>

Then, all of the subsequent projects that are customized per client are considered extensions of this core project.

What you're describing is the basic purpose of any Framework. Namely, create a core set of functionality that can be set apart from the whole so you don't have to duplicate that development effort in every project you create. Ie, drop in a framework and half your work is done already.

<hr>

You might say, "what about the SCM (Software Configuration Management)?"

How do you track revision history of all of the subprojects without including the core into the subproject repository?

Fortunately, this is an old problem. Many software projects, especially those in the the linux/open source world, make extensive use of external libraries and plugins.

In fact git has a command that's specifically used to import one project repository into another as a sub-repository (preserving all of the sub-repository's revision history etc). In fact, you can't modify the contents of the sub-repository because the project won't track it's history at all.

The command I'm talking about is called '<a href="http://git-scm.com/docs/git-submodule" rel="nofollow">git submodule</a>'.

You may ask, "what if I develop a really cool feature in one client's project that I'd like to use in all of my client's projects?".

Just add that feature to the core and run a 'git submodule sync' on all the other projects. The way git submodule works is, it points to a specific commit within the sub-repository's history tree. So, when that tree is changed upstream, you need to pull those changes back downstream to the projects where they're used.

The structure to implement such a thing would work like this. Lets say that you software is written specifically to manage a car dealership (inventory, sales, employees, customers, orders, etc...). You create a core module that covers all of these features because they are expected to be used in the software for all of your clients.

But, you have recently gained a new client who wants to be more tech savvy by adding online sales to their dealership. Of course, their website is designed by a separate team of web developers/designers and webmaster but they want a web API (Ie, service layer) to tap into the current infrastructure for their website.

What you'd do is create a project for the client, we'll call it WebDealersRUs and link the core submodule into the repository.

<hr>

The hidden benefit of this is, once you start to look as a codebase as pluggable parts, you can start to design them from the start as modular pieces that are capable of being dropped in to a project with very little effort.

Consider the example above. Lets say that your client base is starting to see the merits of adding a web-front to increase sales. Just pull the web API out of the WebDealersRUs into its own repository and link it back in as a submodule. Then propagate to all of your clients that want it. 

What you get is a major payoff with minimal effort.

<hr>

Of course there will always be parts of every project that are client specific (branding, ect). That's why every client should have a separate repository containing their unique version of the software. But that doesn't mean that you can't pull parts out and generalize them to be reused in subsequent projects.

While I approach this issue from the macro level, it can be applied to smaller/more specific parts of the codebase. The key here is code that you wish to re-use needs to be genericized.

OOP comes into play here because: where the functionality is implemented in the core but extended in client's code you'll use a base class and inherit from it; where the functionality is expected to return a similar type of result but the implementations of that functionality may be wildly different across classes (Ie, there's no direct inheritance hierarchy) it's best to use an interface to enforce that relationship.

blocks|key|3207750|text|我知道您的问题是泛泛的，与技术无关，但是既然您提到了您实际使用.NET，我建议您看看.NET+4中一个新的、非常重要的技术部分：the+'dynamic'+type.|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3207751|这里还有一篇关于CodeProject的好文章：DynamicObjects+–+Duck-Typing+in+.NET。|3207752|这可能值得一看，因为如果我必须实现您所描述的动态系统，我肯定会尝试基于DynamicObject类实现我的实体，并使用TryGetxxx方法添加自定义属性和方法。它还取决于您关注的是编译时还是运行时。这里有一个关于这个主题的有趣的链接：Dynamically+adding+members+to+a+dynamic+object。|3207753|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/dd264736.aspx|1|http://www.codeproject.com/KB/cs/dynamicobjects.aspx|2|https://stackoverflow.com/questions/2079870/dynamically-adding-members-to-a-dynamic-object^0|1S|J|0|0|O|10|1|0|3A|1A|2|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|H|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]|R|$5|K|L|M|C|$N|S]]]]

I know your question is general, not tied to a technology, but since you mention you actually work with .NET, I suggest you look at a new and very important technology piece that is part of .NET 4: <a href="http://msdn.microsoft.com/en-us/library/dd264736.aspx" rel="nofollow noreferrer">the 'dynamic' type.</a>

There is also a good article on CodeProject here: <a href="http://www.codeproject.com/KB/cs/dynamicobjects.aspx" rel="nofollow noreferrer">DynamicObjects – Duck-Typing in .NET</a>.

It's probably worth to look at, because, if I have to implement the dynamic system you describe, I would certainly try to implement my entities based on the DynamicObject class and add custom properties and methods using the TryGetxxx methods. It also depends whether you are focused on compile time or runtime. Here is an interesting link here on SO: <a href="https://stackoverflow.com/questions/2079870/dynamically-adding-members-to-a-dynamic-object">Dynamically adding members to a dynamic object</a> on this subject.

I am working on a packaged product that is supposed to cater to multiple clients with varying requirements (to a certain degree) and as such should be built in a manner to be flexible enough to be customizable by each specific client. The kind of customization we are talking about here is that different client's may have differing attributes for some of the key business objects. Also, they could have differing business logic tied in with their additional attributes as well

As an very simplistic example: Consider "Automobile" to be a business entity in the system and as such has 4 key attributes i.e. VehicleNumber, YearOfManufacture, Price and Colour.

It is possible that one of the clients using the system adds 2 more attributes to Automobile namely ChassisNumber and EngineCapacity. This client needs some business logic associated with these fields to validate that the same chassisNumber doesnt exist in the system when a new Automobile gets added.

Another client just needs one additional attribute called SaleDate. SaleDate has its own business logic check which validates if the vehicle doesnt exist in some police records as a stolen vehicle when the sale date is entered

Most of my experience has been in mostly making enterprise apps for a single client and I am really struggling to see how I could handle a business entity whose attributes are dynamic and also has a capacity for having dynamic business logic as well in an object oriented paradigm

Key Issues

<ul>
<li>Are there any general OO principles/patterns that would help me in tackling this kind of design? </li>
</ul>

I am sure people who have worked on generic / packaged products would have faced similar scenarios in most of them. Any advice / pointers / general guidance is also appreciated.

My technology is .NET 3.5/ C# and the project has a layered architecture with a business layer that consists of business entities that encompass their business logic

How to Design a generic business entity and still be OO?

数据存储

单元测试

集成测试

系统测试

数据库

Java

我正在开发一个打包的产品，它应该迎合具有不同需求(在一定程度上)的多个客户，因此应该以一种足够灵活的方式构建，以便每个特定的客户都可以自定义。我们在这里讨论的定制类型是，对于某些关键业务对象，不同的客户端可能具有不同的属性。此外，它们还可以将不同的业务逻辑与其附加属性捆绑在一起是一个非常简单的例子：认为“汽车”是系统中...

问如何设计一个通用的业务实体，并且仍然是面向对象的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何设计一个通用的业务实体，并且仍然是面向对象的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何设计一个通用的业务实体，并且仍然是面向对象的？
EN