Question on MVP Pattern, Events and saving complex objects

Question

I'm working on a winforms project that involves 3d models, Opengl graphics, hierarchical project files and uses an MVP approach. Currently i have things setup such that when the user manipulates objects the view is updated using events triggered by the object. For each object that is added to the hierarchy in e.g. a list, i need to add handlers (since i do not have a variable assigned to the object, which could be declared withevents). When storing (serializing) this hierarchy the handlers are not included. So when a project file is opened these handlers need to be setup again, or nothing works anymore. This is cumbersome and i am considering either :

• removing all methods and functions from the respective classes to libraries, so that in the end only data is stored in the hierarchy, and avoiding the use of internal events all together. or
• moving all methods, functions and events into inheritable classes that are not serialized

Since this project has reached a certain 'critical mass' and my limited experience does not allow me to see past my design choices, I am starting to become reluctant to change the setup again and again. So I am wondering if someone with some experience on larger projects can give me some advice ? or perhaps tell me if this approach is going to cause problems in the long run, or better yet give some pointers on handling these issues. In any case, all help is welcome.

Update :

Hi, Thanks for taking the time to answer the question. Based on the input I recieved below I started to read up on topics like Data tranfer objects DTO, Data value or access objects, Domain objects, Business layer, Persistence layer/Data layer and the works. Unfortunately most examples deal with databases and tables, which is not very fitting for 3d worlds, but the essence is now clear to me.

In effect I have now created a data-only representation of my project hierarchy which holds all the data and can be serialized easily. All data objects are plugged into domain objects which add functionality to manipulate the data and provide behavior (i.e. events and handlers). Herein all setters and getters point to the variables in the data object The domain objects also form a hierarchy, similar to that of the data layer. To avoid maintaining lists of handlers, i've hard wired the events for a single object and only change the reference to the one which is active/being manipulated/needs updating etc.

Thus now I have a Model View (passive)Presenter + Data/persistence layer arrangement, which will do what I need. Thanks for the input.

Best PeteByte

Answer 1

I would segregate the persistent data to DTO's that are consumed and produced by full blown long lived objects that were taught what handlers existed were when they were constructed.

Done this way you don't have to create hierarchies or libraries. Persistent data comes and goes. The objects that know how to deal with that data send messages to other objects telling them what they need done.

Each long lived object should be no more complex than is needed to handle a single idea.

I've used this pattern successfully many times. My favorite was a chess AI me and my teammate created (that, incidentally, won the tournament). Each kind of game piece had one object. Even though there are 16 pawns on the board I had only one pawn object. And it didn't know where it was on the board until you told it. I stored many references to it on the board. It's only job was to figure out what it's legal moves were.

I know this flies in the face of the style of "modeling the world as objects" but I've found true object oriented programing isn't done that way at all. Sometimes I create objects for things that don't even exist in the real world.

Don't be afraid to write code driven by your needs rather than some prescribed style. Most people giving you advice have no idea what you're up to.