I'm using Steema's TeeChart for specialized diagrams. I would like to hear if someone has done the following before, and what kind of advice can you give me.
I have a MyDiagram that was inherited from the base TeeChart class, where I set some of the default properties. MyDiagram will contain 3 ReadOnlyLists and I would like to handle my MyDiagram in the same way as you would with Project or Resource, becuase I would like to save MyDiagram with some data into SQL Server DB as with any other BO.
What would be the best approach in combining the 3rd party component with BusinessBase to create MyDiagram BO?
It is important to maintain a clear separation between presentation and business layer constructs. A UI layer type (like your chart) should not be part of the business layer, and a business layer type shouldn't be part of the presentation/UI.
This is what data binding is for - to connect business layer constructs with presentation layer constructs.
I fully understand the concepts you are referring to and I agree totally. I should explain my line-of-thinking better, so here goes.
The chart (there are several types, all related to hydrogeochemistry) has a very, very specific purpose, which only use very specific data. It is widely used in the hydrogeosciences field.
My thinking was that each one of the charts is part of the business, they would each have their individual use cases, i.e. "plot chart", where the chart would then be the BO, not only the data associated with it, but also the actual chart itself. So, the chart BO doesn't only have, IsDirty, Save, etc. but also have Plot or Draw. I can then serialize the chart BO and store it to the database, but also store it as an image for example.
But then, if I were to use a 3rd party component for the actual drawing, would it be re-usable? What if my client decides to acquire another 3rd party tool. This would break my chart BO, because I've included "UI" capability into a BO.
What if the drawing of the chart is independent of a specific tool, but is handled by the BO. If I were to re-use the chart BO, I could for instance use a control like Panel or any other container and draw the chart on the container.
Your thoughts please.
Your instinct is correct - business layer objects should never have methods like Draw() or Render() or Plot() - because it is impossible for the business object to know whether to plot in html, xaml, xml, ChartControlX, ChartControlY, etc. And if you arbitrarily pick one today, how do you know that'll be relevant in 6 or 12 months?
And what happens if you need to render to your control and to xml?? Now you need Plot() and PlotToXml(). What a mess!!
Things like plotting, rendering and drawing are interface concerns and should be handled by interface components - using the information provided by the business objects.
Please believe me, I'm not argueing with you or anything like that. I still agree with you and I believe in the OO approach, but I also like to ponder on what seems impossible.
But what if the BO does know?
Ok, back to the real world before abstraction takes place. My use case is "pour a cup of tea", my BO is "cup". How would the cup know I'm pouring tea into it? It doesn't, but my use case dictates that I want tea.
How is the cup rendering the tea back to me? In only one specific way - contained in the cup, and not in any other form, i.e. spilled next to the cup, or suspended in mid air above the cup, and it is always in liquid form. So the cup does "know" how to render the tea back to me. What happens if I want the tea in another container like a glas, then it would render back differently, because the glas is transparent and I can see it in a different way. What if I want milk and not tea, the cup world still render it back to me in the same way as the tea, but not as with the glas.
I think I'm over-complicating it now...
Thanks anyway for the discussion. Much appreciated.
Unfortunately that's a weak analogy
It is entirely fine for the business object to "be a chart" if the concept of a chart exists outside of any specific representation technology. That sort of thing happens all the time - the idea of a graphic "path" is a series of x,y coordinates. That idea exists independent of any specific representation technology and so might easily be part of the business layer.
But converting the path data, or your chart data, to html, xml, xaml, etc - that is a presentation layer concern, because that is the point at which specific representation technologies become important.
Copyright (c) Marimer LLC