关于以序列化为主要隐喻的六边形架构有什么建议吗？
我有机会重写我的雇主用于文档控制的内部开发应用程序的核心。我的“核心”需求列表是这样的：
- 更容易导入/导出各种格式（文件集合+相当广泛的元数据是共同因素） 更
- 容易添加新字段（其存在是数据驱动的，而不是数据驱动的）全局）在多个层面
- 上引入一些新的功能，这些功能违反了旧系统的基本前提（基本上，围绕文档的元数据的结构正在发生根本性的变化）
- 能力
保持严格控制文档和元数据关系和约定的 一直在尝试一种使用序列化作为与世界通信的主要方式的架构，到目前为止我对结果很满意 - 我可以序列化到 &轻松地从用户界面、XML 存储和数据库进行反序列化，无需修改核心类来适应各种源和接收器。我认为这从根本上来说是一个 六边形架构 - 它以相同的方式处理每个序列化目标（如Serialize 方法的可注入依赖项）。
然而，这是我第一次尝试这种方法，我想知道是否有人有这方面的经验，以及是否有任何见解或建议。
I've got the opportunity to rewrite the core of an internally-developed application that my employer uses for document control. My "core" requirements list goes something like this:
- Make it easier to import/export to various formats (collection of files + fairly extensive metadata being the common factor)
- Make it easier to add new fields (whose presence is data-driven rather than global) at multiple levels
- Introduce several new pieces of functionality which violate the fundamental premise of the old system (basically, the structure of metadata surrounding documents is undergoing a radical change)
- Maintain the ability to tightly control document and metadata relations and conventions
I've been playing around with an architecture that uses serialization as its primary means of communication with the world, and so far I'm pleased with the results - I can serialize to & deserialize from a user interface, an XML store, and a database with ease without modifying the core classes to accomodate the various sources and sinks. I consider this to be fundamentally a hexagonal architecture - it treats every serialization target the same way (as an injectable dependancy for the Serialize method).
This is my first go around with this approach, however, and I'm wondering if anyone has any experience with it, and any insights or advice if so.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的第一直觉是，任何严重依赖于核心类序列化的东西都可能会遇到棘手的版本控制问题 - 对核心的更改将需要同时修改所有序列化提供程序和序列化提供程序。消费者（可能还有所有持久性存储），而不是基于服务/合同的方法，该方法允许接口在可能的情况下保持静态。
然而，如果不对系统将如何使用和使用做出大量假设，就很难给出任何意见。随着时间的推移不断发展 - 如果您对这种方法感到满意，请继续使用它并继续使用它。让我们知道进展如何。
My first instinct is that anything that depends heavily on serialization of your core classes is likely to run into hairy versioning issues - changes to your core are going to require simultaneous modification of all of your serialization providers & consumers (and probably all of your persistent stores), rather than a service/contract-based approach which would allow the interface to remain static where possible.
However, it's really difficult to give any sort of opinion without making a large set of assumptions about how the system is going to be used & evolve over time - if you're happy with the approach, continue with it & let us know how it goes.