Here's my take on this problem. First of all I'm not sure what your problem is, mostly because you choose an example that's a different problem in itself. Working with TRichEdit is easy IF you use an TRichEdit for displaying and editing text, but using it for any other purpose it's bound to be difficult. So I'm going to ignore the TRichEdit sample and talk about the problem in general.
The first step you'd take if you want to separate UI and Business Logic is to create a set of objects that only deal with DATA and Business Logic. To make the separation clear, imagine you're using the objects to read data from a file and manipulate that data without a GUI (from a web page, from a console application). With Delphi it is easy to achieve this if you put all data/business logic classes into different units (separate from the GUI forms). This is not really required, if the application is small you can have both data and GUI in the same unit and still maintain separation. Next you'll need to design a GUI that will expose all Business Logic functions (create Headings in your Word example, change HeadingLevel, etc). The forms/frames you'll create while designing the GUI will USE the classes in the Data/Business Logic units. The GUI may create objects of the types defined in Business Logic, may use those objects, call procedures and functions in the Business Logic and do whatever is necessary to help the final user get the job done. What the GUI should not do is store the data in the GUI! This doesn't mean that there's a very clear distinction between what's GUI and what's Domain. I personally never think about my application in those terms, I just design class hierarchies that are easy to understand, easy to debug and easy to maintain. Usually this means my classes are small and focused. Beyond this I can't help much. You'll need to come back with more precise questions. -- Cosmin Prund On Saturday, October 25, 2008 9:57 PM Alan Colburn wrote: Subject: Separating UI and Domain > I'm still trying to keep my UI and domain objects separate--I very much > see the advantages--but I also keep having similar problems. Here's an > example: > > I'm working on an outliner right now--something that mimics the outline > function in programs like Word and WordPerfect. You create headings and > sub-headings, move heading levels "in," "out," "up," "down," etc. I > have a simple base class to represent an outlineEntry (an individual > line in an outline). It's got properties for the entry's text, > headingLevel, and whether or not it is visible. I also have a > collection of outlineEntry objects. This ObjectList descendant > represents the outline itself. Everything works well. > > The problem comes with the UI. If I want to display everything & work > with an outline via something like a TMemo, there would be no problems. > I'm just passing strings between objects. But if I want to work with an > outline via a TRichEdit control I feel stuck. Although an outlineEntry > object's text is displayed on a line in a TRichEdit, what do I do if > there's rich text? How can you work with individual lines in a RichEdit > control, passing information back and forth with other classes, > preserving rich text formatting (esp. if you also want to save an > outline and its outlineEntries to a file)? ... I could end up doing all > the work of formatting in the UI class, my classes will be tightly > coupled, and I will see less need for keeping the UI and domain > separate (...and we don't want that. "Danger, Will Robinson! Danger!". > > I have this problem all the time--UI form objects' methods using > parameters or creating results in data types that are hard for me to > pass around or work with outside the form class. I'm thinking there is > some fundamental way or mindset involved when objects interact with > each other that I am missing. Can you help me see the light? > > Thanks, as always -- Al C. _______________________________________________ Delphi mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
