Dawa,
Kevin pretty much answered your question about Business and Data Access DLLs (and I obviously agree with him, seeing as it was I who convinced him that this was the way to do it <g>).
Your architecture looks good, although you might want to think about using Web Services to communicate with your server-side processes.
And, while I'd agree with what others have said about using Crystal or SQL Reporting Services for your reporting, depending on your situation using VFP for reports might work out ok. Do you currently have a VFP app with reports that you want to re-use? Starting out with those reports and slowly converting them to Crystal or whatever might get your app out the door quicker. A problem I see with doing it the way you've described it, however, is that you'll have two EXEs ... one for your .NET UI and another for your VFP reporting. Not typically what users would expect to have to do (launch two apps). The only way to get around that, is to call your VFP reporting from your .NET UI as a COM object, and that is not very smooth either!!! All things being equal, I'd opt for reporting through .NET rather than a separate VFP app.
~~Bonnie
>>Well of course there are!! Would we be doing this if it didn't work?
>>
>>Our application is a Records Management System for the fire service (fire departments). It's more than just client/server, it's SOA (Service Oriented Architecture for those that are wondering), meaning we use Web Services exclusively to communicate with the server-side stuff.
>>
>>I'm not sure how many customers we have (I'm not in marketing <g>), but we have large installations (meaning big fire departments with many stations) and they are all happy with the performance of the application.
>>
>>I don't know why Jordan has had such a bad experience with .NET, but we've had no major problems.
>>
>
>Bonnie,
>
>Thank you for the reply. That is very encouraging to hear!
>
>If you don't mind, could you point out any problems with the following architecture:
>
>. Create a class library (DLL) project for business logic in C#;
> This DLL will be responsible for creating a connection to,
> querying from, updating to and deleting records from,
> the database in SQL.
>(Kevin Goff and others did point out that I should separate the Data Access and Business Logic. Though, I didn't quite understand what they meant by that. How are you guys doing it, if it it not problem for you to share this?)
>. Create a second project (exe) for user interface using Win Forms in C#.
> This will reference the business logic DLL and data access DLL and will
> accept inputs from the user and update the user's screen
> appropriately.
>
>. Create a project in VFP 9 which will be used purly for querying the database and running reports. (For reporting purpose, one does need to pull alot of records, so I thought to take adventage of VFP's local cursor engine power)
