从复合控件获取数据 - 访问者模式？
我有一些相当复杂的表单，需要由网页设计师进行配置。
我一直在构建一些似乎可以完成这项工作的复合控件。
顶层控件只是一个容器，其中包含表单的各个部分。 SubControls 实现通用接口，（即 NeptuneAddressControl 和 MarsAddressControl 实现 IPlanetaryAddressControl）
最终，所有内容都需要进入同一个数据库。
我不想将子控件的每个字段都公开为父控件中的 prop，而是考虑实现一个跨越控件树的访问者，并填充一个可以写入数据库的实体对象。
这是正确的方法还是我在这里偏离了基地？
I've got some rather complex forms, that need to be configured by web designers.
I've been building some composite controls that appear to be doing the job.
The top level control is simply a container, and the sections of the form are contained within. SubControls implement common interfaces, (i.e. NeptuneAddressControl and MarsAddressControl implement IPlanetaryAddressControl)
Ultimately, everything needs to go into the same database.
Instead of exposing every field of the child controls as a prop in the parent, I'm thinking of implementing a Visitor that will span the control tree, and populate an Entity Object that can then write to the database.
Is this the right approach or am I way off base here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为使用属性映射和访问者之间的权衡是实现访问者需要了解所有可能的属性的类，而处理映射的代码可以独立于表单/数据库的内容。
有了访问者，当新类型的数据添加到结构中时，您的代码无法编译，您会受益匪浅，因此如果您要更改复杂的结构，编译器可以帮助您。
如果稍后添加新字段或控件，属性的好处可能会导致代码量减少，根本不需要更改中间层，具体取决于您可以使该代码变得多么通用。
我想还有其他选择，但我认为访客方法是有意义的。 您可能想要做一些特定于控制的事情，例如专门的验证，这些事情很难通用地编码，因此任务会更容易，并且应该很好地防止由于控制结构的更改而导致的隐藏错误。
I suppose the trade-off between using a map of properties and a visitor is the class implementing the visitor needs to know about all possible properties, whereas code that deals with a map can be independent of the contents of the form/DB.
With the visitor, you get the benefit of your code failing to compile when new sorts of data are added to the structure, so the compiler can help you out if you're changing a complex structure.
The benefit with properties may lead to a smaller amount of code with no need to change the middle layer at all if new fields or controls are added later, depending on how generic you can make that code.
I suppose there are other alternatives, but I think the visitor approach makes sense. There are probably control-specific things you want to do like specialized validation that will be harder to code generically, so the task will be easier and should do a good job of prevent hidden errors due to changes in the control structure.