mercredi 30 août 2023

How should I go about making a list of items with subtly different behavior?

I'm starting work on a new project, based on a node editor workflow. I'm using WPF, with Nodify as the central driver. That forces an MVVM model, but I'm planning on adding a computation layer entirely separate from that, because I want to abstract away some of the details that are relevant to the visual representation (such as the position or amount of connectors a node has). It will have about 30 types of nodes, with similar behavior in terms of user interaction but with different parameters. And I've come to a dilemma: how do I organize that? I've come up with a few different solutions, but I'm not really sold on any of them and I'm open to other ideas.

  1. Spend a few hours working on a modular plugin system, and build each node type as a separate .dll file that later gets loaded dynamically. This has the advantage that one file can contain both classes relevant to the frontend (such as their ViewModel) and to the backend logic. However, this complicates the file structure and requires a dynamic loader. And there won't be a need for user-defined nodes, nor do I think that there will be enough changes in the future to benefit from smaller updates.
  2. Create a directory with a file per node type, that includes both presentation and logic code, and then manually make a list of them where it's relevant. This has the benefit of a straightforward implementation, but adding any new types will require changes in at least two places and sounds like a nightmare to maintain.
  3. Try to squeeze the logic as a part of the MVVM model. I'm not sure how I would go about doing this, as it requires stripping away some information and adding information that will not be stored anywhere persistently, and will be destroyed after the computation ends. This leads me to think that there is no place in MVVM to store it. And the analysis performed on the graph resulting from the transforms will require access to data from all nodes, as nodes won't be able to do the required calculations by themselves.

This doesn't seem like an uncommon issue, so I assume there is a design pattern already for it, but wording this issue has proven to be difficult enough to discourage me from looking for one.

Aucun commentaire:

Enregistrer un commentaire