The business layer was the only one that there was even a ripple of discussion as to whether Foxpro would not be replaced, but it was decided to totally remove Foxpro from our corporate shop. Period. Now, if you have any non-data-centric thoughts you would like to share, I would love to hear them.

>Jay,
>
>So you decided to use rather static business rules rather than high tec flexibility on the biz layer ? Why are you going backwards on this layer ? If you want to go forward why do you dismiss the future by having a robust, flexible and clean implementation of the biz layer ? This can be most effictively done by using data centric solutions, not by static code languages like C# (you'll have to use a lot of reflection here) or Java (I have no clue how to do this in Java).
>
>Walter,
>
>
>>Walter, with all due respect, if we were going to stay with a data-centric approach, we would stay with Foxpro. It has already been decided that we are not going to be using Foxpro in the future.
>>
>>>Renoir,
>>>
>>>
>>>>We are moving from Foxpro to something else. That's the whole premise of this thread. We're not deciding if we are moving; we are moving.
>>>
>>>You asked for recommendations. I gave you a recommendation for the business layer, and if you read it carefully I did not say that it *has* to be written in VFP. I only recommend to do it in a language that is more data centric *like* vfp. If you don't appreciate my thoughts on it, why did you post the question here ??
>>>
>>>For example, I'm not too familiar with PHP or Python, but I would look into these options as well, *if* you already decided (for whatever reason) to go away from the fox. By their nature they might give you more power and flexibility than hardrock implementation in C# or Java.
>>>
>>>Walter,
>>>
>>>
>>>
>>>
>>>>>Renoir,
>>>>>
>>>>>From an architectual view, I'd say that keeping you business rules layer in a data centric programming language (like VFP) makes more sense than trying to do this in a low level language like Java or .NET. It might pay off when business rules are less static. You can store the business rules in a table, and process them in VFP very clean and quickly. This is much harder to do in .NET or java technologies.
>>>>>
>>>>>In very much the same way we have build a HL7 parser: Code in a table, that might be different for each and every client for each and every message type, without having to compile.
>>>>>
>>>>>Walter,
>>>>>
>>>>>
>>>>>>We are looking towards moving everything away from Foxpro and towards a new technology. Probably over 3 to 5 years. These are the layers we initially outlined:
>>>>>>
>>>>>>Presentation Layer - Thin client and some thick client (browser-based, Java, C#).
>>>>>>Application Server Layer - Handle requests from Presentation Layer and outside sources (Java or C#).
>>>>>>Business Rules Layer - Interpret requests and return/update data in the Data Layer (Java or C#).
>>>>>>Data Layer - SQL Server or Oracle.
>>>>>>
>>>>>>Any very general recommendations as to whether C# or or Java would be better choices? Is there a right and wrong combination of languages across the layers?
>>>>>>
>>>>>>Looking for some very broad thoughts here.