对象来模拟即将创建的数据库。
比方说，我有一个包含“小部件”的数据库。例如，小部件具有长度和宽度等属性。最初用于创建wdiget的低级API是一团糟，所以我正在编写一组更高级别的函数，以使调用者更容易。数据库很奇怪，我无法很好地控制创建小部件对象的时间。具体来说，在某些其他事情先发生之后，直到处理的后期阶段才能创建它。但是我希望我的调用者认为在早期已经创建了一个小部件对象，这样他们就可以从一开始就获得/设置它的属性。
因此，我实现了一个"ProxyWidget“对象，我的调用者可以使用该对象。它有诸如private_Length和private_Width这样的私有字段，可以存储所需的值。然后，它也有公共属性的长度和宽度，我的调用者可以访问。如果调用方告诉我设置宽度属性的值，则逻辑是：
- 如果相应的小部件对象已存在于数据库中，则设置其宽度属性。
- 如果没有，请将给定的宽度值存储在private_Width字段中，供以后使用。
在以后的某个阶段，当我确信小部件对象已经在数据库中创建时，我会复制所有的值:从private_Width复制到数据库宽度字段，等等(不幸的是，每次只有一个字段/属性)。
对于一种类型的小部件来说，这是可以的。但是我有大约50种类型，每种类型都有大约20个不同的字段/属性，这导致了不可维护的混乱。我想知道是否有更聪明的方法。也许我可以使用反射来创建“代理”对象，并以一种通用的方式复制字段/属性数据，而不是编写大量重复的代码？从某种程度上算出了通用代码？我能从“数据绑定”模式中学到什么吗？我是一个数学家，不是一个程序员，我有一种不安的感觉，认为我目前的方法太愚蠢了。我的代码在C#中。
回答 1
Stack Overflow用户
发布于 2013-03-30 11:12:27
首先，在我的经验中，手动编写数据访问层的代码可能会感觉到很多重复的工作(将ORM放在适当的位置，例如NHibernate或Entity，可能会在一定程度上缓解这个问题)，而更新遗留数据访问层是件很糟糕的工作，特别是当它由许多部分组成时。
有些事情在你的问题中还不清楚，但我认为仍然有可能给出一个高层次的答案。这些是为了给你一些想法：
- 您可以将
ProxyWidget构建为Widget的替代实现(或调用现有低级别API中的小部件类)，也可以“基于”实现它，也可以将其作为“包装器”Widget实现。这是适配器设计模式。 公共密封类ExistingTerribleWidget {…}公共密封类ShinyWidget //这是位于上述{公共ShinyWidget(ExistingTerribleWidget基础){…之上的包装器。}基础的私有ExistingTerribleWidget；…//通过适当地委托给underlying来执行所有实际工作 我建议您使用此模式，而不是创建一个完全独立的Widget实现(至少在仍然使用现有的低级别API的情况下)，因为如果发生数据库模式更改，则必须更新两个不同的API。如果您将新的EasyWidget类构建为在现有API之上的包装器，它可以保持不变，只有底层实现才需要更新。 - 您将描述
ProxyWidget具有两个功能：(1)允许对已经持久化的小部件进行修改；(2)新小部件的缓冲区，稍后将添加到数据库中。 如果您有一个公共基类型和两个子类:一个用于尚未持久化的新小部件，另一个用于已持久化的小部件，那么您也许可以简化设计。后一个子类型可能有一个附加的数据库ID属性，以便可以在数据库中识别、加载、修改和更新现有的小部件： 接口IWidget { /*定义小部件*/ }接口IWidgetTemplate所需的所有属性: IWidget { IPersistedWidget Create()；bool TryLoadFrom(IWidgetRepository存储库，out IPersistedWidget matching)；}接口IPersistedWidget : IWidget { Guid Id { get；} void ()}； 这是建筑商设计模式的一个例子。 - 如果需要为许多类(例如，50+数据库对象类型)编写类似的代码，则可以考虑使用T4文本模板。这只会减少编写代码的重复性；但是仍然需要在某个地方定义50+对象。
https://stackoverflow.com/questions/15717662
复制相似问题
腾讯云开发者
