I've just completed a project and while it works well from the user's perspective, I'm not completely satisfied with the underlying design and was wondering how other SF developers address the following situation. SF provides a one-to-one mapping between a business object and data base table. However logically, a business object might be made up of a core database table and a number of associated tables. For example a customer might be represented by a core table that contains the customer ID and name along with an associated table that contains addresses.

The most direct approach to dealing with this is to drop all of the objects on a form and add the code to the form to keep the individual objects in sync and possibly update them all on a transaction. My issue with this is that it places what I consider to be business logic in the UI.

Another approach is to create a complex business object based on the core table that exposes the associated tables as properties. This allows all of the logic that maintains the relationships to reside in the complex BO. The problem with this approach is that you cannot bind to a property such as 'customer.address.zipcode'. This can be addressed by exposing the individual properties of the contained business objects as custom properties of the complex BO, but you have to manually code the custom properties and property descriptors. And if you change an underlying table you have to update all that custom code. While I feel this approach provides a more object oriented design, all the extra manual coding undermines the productivity gains of the framework.

Any comments and/or suggestions would be greatly appreciated

Michel,

Thanks again for your input. I have just a few items in response.

We do not have the budget to purchase the SF Enterprise Server. We see a great benefit in the product, but the cost is too prohibitive. We package/deploy/support our applications as if they were commercial apps, but our customers pay nothing to use them, so we cannot use a product without a royalty free runtime.

Thanks for your insight regarding VFP and linked server. I'm very interested in your VFPinSQL project and would like to read anything you might post to the community.

The reason for a SQL server on both sides of the WAN is that I need to access both VFP databases in the SF app on both sides of the WAN (without an SF Enterprise Server). The idea would be to set up the VFP database to the local SQL server as a linked server, then both SQL servers would be linked together as linked servers. If one of the SQL servers is not local to the VFP data, then the VFP data would have to be pulled across the WAN, which is not an option. Does that help to explain why there are 2 SQL servers in the design?

William,

I understand the 2 SQL servers on both sides, and also the fact you have not the budget for ES.

VFP data are local in each side of the WAN, are they? and will stay local, during all the smooth migrating process? If yes, then go with BO directly mapped on your VFP tables. And keep the SQL Servers as linked servers if you need it.

About VFPinSQL: we'll present it on march 23, at Montpellier (France). Maybe we shall put the code on CodePlex, but we don't know when. And now, we need to find a solution for the NULLs , and also for a problem with grants on automation .