I am planning to convert a large Visual FoxPro Application and I am trying orient my thinking to the Xojo way. In VFP I used three tiers: the user interface, business objects and the database. This allowed me to use the business objects separately from the user interface when I wanted to automate tasks such as export data or run a report on a schedule. These can all be done from the user interface but since the logic resides in the business object I could simply create the business objects and then call their methods when I wanted to automate this tasks without user input. In fact I use some of the business objects in my web applications.
In Xojo I cannot see a class that would be a candidate for a business object that could be used alone or added to a Window so I am wondering what is considered best practice in Xojo for this type of thing. Does anyone bother with business objects? If not how do they avoid duplicating code when a feature should be available in the user interface or separately for use with windows services etc.
Your line of thought appears to be referring to a 3-tier architecture.
With Xojo, that could be a database server, and as Tim indicated, a class or a set of classes that manage the business objects and the business logic, and finally the UI layer, made of the windows and possibly some specific classes also.
If you are looking for further separation of the business logic (in the way that some ERP systems have an “application server” in addition to the database and the GUI application), then you could look into using threads that launch helper applications. The helper applications would execute the business logic functions and return results to the UI app. This is also a way to spread the work among multiple processor cores, if you need the performance gain. There are a number of threads on the subject in the forum.
There’s many ways to skin this cat
In a single app you might have UI, “model” classes that model the data(business objects), and a db layer
Now if you wanted you could move all those layers to separate machines - with appropriate changes to communications layers between them as in a single desktop app you instantiate a class & call its methods, whereas on a set up where each layer resides on its own machine you need some other means to do this.
Why would you ever want to split the business objects into it’s own layer/machine like this ?
Scalability and consistency.
If the business object layer is some set of web based functionality you can access from a desktop app, mobile app etc then ANY UI will do.
And you can more than like implement lots of caching & such in the business object layer so that you don’t pound the DB
And you might even be able to split that layer out across several machines acting in concert (this is how web objects works & can scale enormously - it runs the Apple iTunes store)
The question then is do you need to go to this extent ?
I was looking through the help file and did not notice any command to just create a class. However now that I am looking in the IDE I see that I can just create a class so my question is easily answered.
Remember that you can create a number of different classes and then create a super class that uses these classes and adds additional data/methods to create a Business Object.
Example, create a class for a client and a class for addresses. Then create a class for a person that uses the client and multiple address classes (objects/instances) within.
One of the disconcerting things about moving from VFP to Xojo is that you don’t ‘see’ the subclassed methods in the IDE. However, with the strict typing, you get the intellisense to help you.
I’d suggest running a test on a new small project. Create a base business class, subclass that to another class. Add methods and properties, and make sure you can call them from your Window the way you expect. It’s worth taking this time up front to make you more efficient and prevent refactoring down the line.
