On 10/12/03 15:34 +0530, Parul.Mathur wrote:
Hi,
Hiya.
I am trying to port a large and complex application to Linux. I have identified two approaches by which this can be done. I was hoping to get advice on which is the best approach, as well as the pros and cons of each approach.
I see you have still not learnt to wrap lines :).
<snip good analysis>
This is more work compared to Option 1 but there is one advantage. The same source code than can be recompiled for Mac and Unix versions also.
Does anybody on this group have practical experience of working with either of the two alternatives? What approach would you recommend I follow?
Option 3: Refactor the application, have it talk to a database via a wrapper module (or ODBC). Separate application logic, business logic and UI logic totally. The UI merely deals with the user interface part, formatting the data, and dealing with changes. The business logic part resides in a separate module which handles data validation and business rules. The database does application logic and data validation via stored procedures.
Once you can do this separation, then your business logic can be coded in whatever language you like, and the UI can be in the same or different languages. Logical choices for the UI are Delphi, QT, GTK+, Tk (if you are willing to release source). Delphi is a good tool when doing rapid application development (think of it as the VB of Linux when dealing with user interfaces, except that it doesn't have the bad featuritis of VB).
This isn't much more work than option 2, but it can give you a much more maintainable codebase, which can easily be scaled up later. The database wrappers ensure portability between various RDBMS systems, while separation of business and UI logic means that you can change backend rules *without* changing the UI.
Having a separate component for the business logic which is centralized also means that no user needs to talk directly to the database, enhancing security.
Devdas Bhagat