以 UI 为中心的应用程序的单独演示
我无法找出此类应用程序的正确架构：它是一个图表应用程序，类似于 MS Visio。这些图表用于生成传递到另一个应用程序的数据。
在设计应用程序时，我一直尝试使用分层，但现在当数据与表示如此紧密地耦合时我无法决定如何做到这一点。例如，我的画布中的某个对象有一个（X，Y）数据，该数据仅用于演示目的，但必须像域数据一样存储。
我哪里搞错了？我很确定我从错误的角度看待这个问题，但我无法找出正确的角度。
再次感谢！
更新：
我也知道也许在这种情况下我不应该将用户界面与域分开。如果是这样，请向我提供一些关于何时申请分居、何时不申请分居的合理理由。
I having trouble figuring out the correct architecture for this kind of application: it's a diagramming application, which resembles MS Visio. The diagrams are used to generated data which is passed to another application.
When designing applications, I've always tried to used layering, but now I can't decide how to do this when the data is so tightly coupled with the presentation. For example, a certain object in my canvas has a (X,Y) data, which is used for presentation purposes only, but has to be stored like domain data.
Where I'm getting things wrong? I'm pretty sure I'm looking at this from the wrong angle, but I can't figure out the right one.
Thanks again!
UPDATE:
I'm also aware that maybe I shouldn't be separating UI from domain in this case. If that is so, please provide me with some rational of when to apply separation and when not to.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在绘图工具中，形状的 x/y 位置是域数据的一部分（形状的位置是图表的一部分 - 没有它就无法绘制图表），使用这些 x/y 坐标并绘制的代码屏幕上的形状是表示层的一部分。
我知道有些人认为仅用于显示的数据应该单独保存，但在我曾经处理过的每个单独保存数据的项目中，这变成了巨大的维护和支持噩梦。
在简单的图表工具中（如果该工具只是绘制和编辑图表，而不基于图表进行任何花哨的处理），则没有业务逻辑，只有绘制和编辑图表的代码（属于表示层）和图表数据（即领域模型）。
如果没有业务逻辑，通过使用一组单独的域对象和表示对象，您将必须将所有模型数据复制两次（一次在模型对象中，一次在表示对象中），并且您不会获得任何优势将业务逻辑与表示分离（因为没有任何逻辑）。
另一方面，如果您确实有一些在数据上运行的算法，那么通过将图形数据与绘图代码分离，您确实可以获得一些好处 - 您可以在工具之外运行算法，您可以进行更好的自动化测试等。
此外，如果您编写另一个处理相同数据的系统，如果将其与绘图代码分开，您至少可以共享模型定义和保存/加载代码。
因此，我们总结一下：
所有图表数据都是模型的一部分（包括仅用于演示目的的数据）。
任何绘制到屏幕或处理用户输入的内容都位于表示层（显然）。
如果这两者涵盖了您的所有代码和数据，那么您的应用程序就没有任何“业务逻辑”，并且层分离可能太过分了。
如果
如果您有任何代码不适合这两个类别，并且您认为它应该成为模型的一部分，那么您应该构建两个单独的层。
如果系统之间有任何代码共享的机会，您应该确保共享代码不与演示文稿代码混合。
如果系统之间有任何代码共享的机会，您应该确保共享代码不与演示文稿代码混合在一起
最后一个“奖励”点 - 如果这是一个可能会在很长一段时间内积极开发的项目，并且将来会添加新功能 - 您可能希望无论如何都将 UI/数据分开，以便将来工作更容易 - 您必须决定现在是否值得为未来节省额外的时间，以及这种分离是否真的可能在未来有所帮助。
In a diagramming tool the x/y position of a shape is part of the domain data (the location of the shapes is part of the diagram - you cant draw the diagram without it), the code that use those x/y coordinates and draw a shape on the screen is part of the presentation tier.
I know some people think that data that is only used for display should be saved separately, but in every project I've ever worked on that saved data separately this turned up to be a huge maintenance and support nightmare.
In a simple diagramming tool (if the tool just draws and edit the diagram without any fancy processing based on the diagram) there is no business logic, there's only the code that draws and edit the diagram (that belongs in the presentation tier) and the diagram data (that is the domain model).
If there is no business logic, by using a separate set of objects for domain and presentation you'll have to duplicate all your model data twice (once in the model objects and once in the presentation objects) and you won't get any advantages from separating the business logic from the presentation (because there isn't any).
On the other hand, if you do have some algorithms you run on the data you do have something to gain by separating the graph data from the drawing code - you can run the algorithm outside the tool, you can have better automated tests, etc.
also if you write another system that operates on the same data you can at least share the model definition and save/load code if you separate it from the drawing code.
So, let's summarize:
All the diagram data is part of the model (including data only used for presentation purposes).
Anything that draws to the screen or handles user input is in the presentation tier (obviously).
If those two cover all your code and data than your application don't have any "business logic" and the tier separation is probably overkill.
If you have any code that doesn't fit into those two categories and you think it should be part of the model than you should build the two separate tiers.
If there's any chance for code sharing between systems you should make sure the shared code is not mixed in with the presentation code.
And one last "bonus" point - if this is a project that's likely to be in active development for a long time with new features added in the future - you may want to separate the UI/data anyway just to make future work easier - you have to decide if this future saving is worth the extra time now and if this separation is really likely to help in the future.
我认为你需要确保将内容和方式分开。您所显示的是抽象的、坐标集、形状类型。你如何展示它是非常具体的。我会确保领域模型纯粹处理“内容”，而视图层则唯一处理“如何”。尽管不了解有关您的应用程序的更多信息，但很难了解具体细节。
I think you need to make sure you're keeping the what and the how separate. What you are displaying is abstract, sets of coordinates, shape types. How you're displaying it is very specific. I'd make sure the domain model dealt purely with the what and the view layer dealt uniquely with the how. It's hard to get into specifics though without knowing more about your app.
您可以尝试实现某种视图模型，它可以保存对象的当前布局。这样，x/y 值与对象的 id 一起存储在布局文件中，而纯模型数据存储在其他地方。
也许这有点帮助，
You could try to implement some kind of view model, which saves the current layout of your objects. This way, x/y values together with the id of the object are stored in a layout file while pure model data is stores elsewhere.
Maybe this helps a bit,