using tie in a untested design pattern
Posted on 2005-05-14
problem: Need to have two way communication between a Perl application and a VB .NET application using a relational database as an intermediary.
solution: From the PERL application, use tie::dbi to connect hash objects to tables in a database. From the VB .NET side, use the .NET framework to connect to tables (managed by the PERL application) to the VB .NET application content (ie relate a label caption on a form to a table element, etc.). The PERL application will READ_ONLY state information (such as button clicks) from tables generated by the VB .NET application. So Perl will act as the event handler in terms of the business logic and content.
0. I am using a 3-tier model.
1. I have a bunch of business logic written in PERL (middle tier, tier2).
2. VB .NET is to be used as the GUI and event generator (presentation tier, tier1).
3. I am using SQL Server and relational database (data tier, tier3).
So, what I would like from the experts here is any advice they have about this design pattern. Do the elements of the solution, and their relationships make "sense"? What are the flaws in this pattern? Is it worthwhile for me to pursue this solution?
You see, if it is not, then I cannot use PERL. I have to port all of the business logic from Perl to some .NET language (probably VB .NET).
I'm addicted to PERL, but have professional requirements with .NET. I'd like to marry the two using this design pattern. Any comments on this would be appreciated.