I'm now writing a program, which will allow processing data expressed in the form of graphs. These graphs will determine workflow of the processing and they are actually an essence of this program (in terms of being the main object being edited by the user).
It is very, very tempting to put all the processing, data containment and presentation in a single control, which will also display these graphs and handle user interaction. From one side it seems to be violation of the presentation/logic rule, but from the other I'm certain I will write surely at least 2x or 3x less code, because I won't have to take care of constant synchronization between data model and the control, which will present this model (+encapsulation, interfaces, proxy classes etc.)
I'm wondering how it is done in editors like Word. Is the data displayed by the control really physically separated from the presenter or are they combined? If you use the Word document control in your program, you ask the control to perform operations on text, what would suggest, that there is no separation (but we don't know how does it work under the hood).
So the question: is separation between data presentation and logic worth it even if it requires like 2x or 3x more code to keep everything consistent and synchronized? (yes, I mean 2x or 3x).
I've described the situation in more detail in the next question: https://stackoverflow.com/questions/22373108/how-to-separate-logic-from-presentation
Best Answer
I personally prefer loosely coupled layers my code. In your case, I would have few interfaces with my implementation. However, I would also like to provide an opportunity to consumers to play around with certain things.
So, I would start with interfaces that provide data to my graph. Assuming it uses data coming in from a database, I could use a database layer that works with
IDbConnectionand other such interfaces. Now, I can support anything that has a provider that uses these interfaces.Next is processing. Once data is available we need a generic way to pass it around. So, think of some more interfaces that help you do that. And your Model (class whose instance would represent data) must implement it. This enables adding and removing business rules easily.
Now, the appearance. For controls, I prefer using public events with a default handler embedded in the control itself along with properties. For instance. on click a bar in bar chart, it's color should become say red. Now a consumer likes green, so, give a property for him to do it. He also wants a tool tip and some more details on mouse hover. So, give him a event to handle.
I understand this is way too generic and hope it is at least somewhat helpful.