Author Message
 Posted 1/30/2008 4:44:18 AM
Advanced StrataFrame User

Advanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame User

Group: Awaiting Activation
Last Login: 3/2/2020 12:19:05 PM
Posts: 595, Visits: 3,807
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 appreciatedSmile

Post #13841
Add to Twitter Add to Facebook
 Posted 1/30/2008 6:02:18 AM
Strategic Support Team Member

Strategic Support Team Member

Group: Forum Members
Last Login: 10/6/2011 5:13:18 AM
Posts: 2,019, Visits: 6,605
I don't really have any magical ideas about how to accomplish this. I've done both (individual BOs dropped on the form and using custom properties to access extended BO functionality) and neither is ideal, for the reasons you've stated.

It did get me thinking about what I'd like though BigGrin

It seems to me that ideally, if a BO could have another BO as a property, and if binding could occur (your customers.address.street example got me thinking), it would be sweet. In the example, the CustomersBO would have a property of an AddressBO. This is of course possible now, but I don't believe there could be any binding in a form designer. This would continue to leverage the framework by using the BOs, but also allow for more complex scenarios. Not sure if this is a helpful idea....Unsure

I'm going to think on this some more. Great question Larry!
Post #13844
Add to Twitter Add to Facebook
 Posted 1/30/2008 9:15:25 AM
Strategic Support Team Member

Strategic Support Team MemberStrategic Support Team MemberStrategic Support Team MemberStrategic Support Team MemberStrategic Support Team MemberStrategic Support Team MemberStrategic Support Team MemberStrategic Support Team MemberStrategic Support Team Member

Group: StrataFrame MVPs
Last Login: 6/15/2019 1:08:46 AM
Posts: 1,920, Visits: 21,109
Hi Larry.

Funny this coming up now... I've been learning a lot about this subject lately, and will try to expose the ideas, so I can be part of the discussion and see if I can consolidate some knowledge.

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.

What if you created an Object Model class, a shared class handling the transaction for you. You could call it from your form, no need to create an instance of it, as it is shared, pass on your BOs as parameters and process whatever you need to do in it. You can start your Transaction, do whatever in a Try/Catch, etc.

These Object Models could reside in you Business Library, with the BOs.

Would that be a layer of Business Logic you are looking for?

Post #13846
Add to Twitter Add to Facebook
 Posted 1/30/2008 9:35:34 AM
StrataFrame Novice

StrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame Novice

Group: Forum Members
Last Login: 9/2/2016 2:32:10 AM
Posts: 84, Visits: 324
I had a similiar discussion as well this week.     In fact I would like to see the BO Mapper get super intelligent and based on the Foreign Key relationships automatically link all of the objects together in a super class.   This is a feature that would be killer as part of the framework.    I'm sure that it isn't too hard to link the events and do it yourself but the time savings would be immense.  It would combine the power of Dataset style development but with Strataframe's unbelievable framework.

Thanks,

Richard

Post #13847
Add to Twitter Add to Facebook
 Posted 1/31/2008 3:30:45 AM
StrataFrame Developer

StrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame Developer

Group: StrataFrame Developers
Last Login: 5/16/2018 3:20:37 AM
Posts: 2,982, Visits: 2,482
Much of the current design energy within StrataFrame is focusing on moving toward an Entity/Collection model that will follow the relationships defined within the database.  Therefore, you create a Customer business object which is stored in a CustomerCollection when you have more than one of them.  This Customer object then has a property on it called Addresses which is an AddressCollection.  Much more intuitive than the single-bo route. 

However, that doesn't much help you here and now, does it?  We do some stuff similar to this with our business objects that we create for reporting.  I can see if I can get together a sample of how we expose those properties.  You would have to use a BindingSource (a generic .NET one, not a BBS) to bind to the controls (like the rest of the world does Smile).  Essentially, you create a property on your CustomersBO called Addresses and it returns a BusinessBindingSource that contains a business object of type AddressesBO.  You then fill both of the BOs when you fill the customer record and the BindingSource knows how to access the Addresses property because it's a list.

Post #13858
Add to Twitter Add to Facebook
 Posted 1/31/2008 3:51:26 AM
StrataFrame Developer

StrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame Developer

Group: StrataFrame Developers
Last Login: 11/20/2019 8:57:25 AM
Posts: 6,610, Visits: 6,776
I am not sure that the entity collection stuff would resolve your problem entirely.  Though it might help, and what Ben was talking about as it relates to our reporting and the way we setup or BBS datasources, this is still going to require some manual code at some point.

In our medical software, we have a PhoneNumbers table that can be used by basically any parent table that has the need for unlimited phone numbers (we actually use it for any parent table that has a phone number period).  So now let's assume that I am on a patient record and I want to retrieve the primary and secondary phone numbers for reporting or display purposes (or even to update).  We expose a custom property for Primary and Secondary as these are the two that you generally deal with, but we have a shared class that all BOs that need to deal with phone numbers uses.  We also have a PhoneNumbers property that has all of the phone numbers for that patient that exposes an object model for the phone numbers (i.e. a PhoneNumber class that has all of the properties that relate to a phone number).  The only reason we have more than one property is for ease of display as it relates to items such as a report.  The PhoneNumbers collection is generally what we deal with as it relates to binding, etc.

This still aludes to a entity/object type of interface, and there will always be some level of manual setup, but if there is a structure change, the BO will not have to be modified, only the shared class that talks to the PhoneNumbers table directly.  I hope that makes sense.  But you are ALWAYS better of putting this code in an object model or BO or base BO rather than in a form so that you do not have to "reinvent the wheel" over and over again.

Post #13865
Add to Twitter Add to Facebook
 Posted 1/31/2008 4:54:50 AM
StrataFrame User

StrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame User

Group: Forum Members
Last Login: 7/18/2016 7:44:52 AM
Posts: 414, Visits: 2,849
Hi guys

I have wrestled with the same problem.

At first was was doing as Larry stated and using the form as a container to house the logic to keep the releated business objects in sync as well as specific logic such as creating child records or whatever and keeping the business ruled in the business object.

Then I tried putting logic directly into the business object but this can get really hairy and caused me to have things blow up in my face.

What I am trying now is to put everything into a "super" class that is made up of several business objects. It basically acts like a business object container and contains logic specific to that entity. It kind of adds another layer to the business layer I leave the SF business objects in charge of common stuff such as required fields and table specific business rules and I add code that is specifc to a group of related business objects in the super class.

For instance I have a customer class that contains CustomerBo,AddressBO and several more business objects I also have and Employee class that contains EmployeeBo,AddressBO and several others. And I have logic that is common to all addresses in the regular SF addressbo and logic that is specific to a customer address in the that super class.  To have databinding work you still have to drop whatever business objects on a form and then wire them up to the business objects contained in the super class, and everything works fine.

Think of what I am doing as a container like the SF form except it is a class that inherits componentmodel.component instead of windowsforms.form . U drop you business objects into the class then write whatever code you need to make them play together the same as you would do if you dropped them on a form.

I hope this makes sence.

Post #13870
Add to Twitter Add to Facebook
 Posted 1/31/2008 7:26:54 AM
Advanced StrataFrame User

Advanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame User

Group: Awaiting Activation
Last Login: 3/2/2020 12:19:05 PM
Posts: 595, Visits: 3,807
Thanks eneryone for all the inputExclamation It's nice to know that I'm not the only one wrestling with this issue.

Basically what I ended up doing in my last project follows Paul's approach. Rather then expose the properties of the contained BOs as custom properties in my complex BO, I dropped the individual objects on the form and wired them up to the contained objects (exposed as properties). This solved the data binding issue but is still not as clean a solution as I would like.

I like Richard's comments regarding a super intelligent BO Mapper that understands Foreign Key relationships and is able to link all of the objects together in some super class along with all the persistance logic. This is similar to a competing framework from a company here in the San Francisco Bay area. However I'd settle for the ability to define my own super class in BO Mapper telling it which objects to incorporate, have it generate a class that contains the individual objects along with all of the properties to support SF data binding, and leave the relationship coding to me. I believe this follows what Greg was suggesting. Coding properties is so boring and time consuming and having BO Mapper create them and doing the data binding in the form designer are such great features.

Ivan's idea of using a shared class to handle transactions is something I hadn't thought of but I think I would still need a complex object to handle the specific relationships between the objects I combined. For example in my last project I had an ActivityLog object that's not exposed to the user but get updated depending on the actions taken on the complex BO.

Long term it seems like the Entity/Collection model will address many of these issues. In the meantime I'll explore the suggestions made by Trent and I'd like to see the sample that Ben discussed added to the samples library on the forum.

Thanks again for all the comments.

-Larry

Post #13879
Add to Twitter Add to Facebook
 Posted 1/29/2011 8:01:25 AM
StrataFrame Novice

StrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame NoviceStrataFrame Novice

Group: StrataFrame Users
Last Login: 12/8/2014 4:29:38 AM
Posts: 80, Visits: 239
Starting to explore the world of StrataFrame Business Objects.... searching the forums for tips and suggestions on BO design. I too am very interested in an Entity/Collection object model, or something akin to the SuperComplexBO described in this thread, but the app I'm working on is not a designed from scratch project that can be modeled to fit the SF framework. It's something that more than likely will require using the current database schema so the existing app can continue to live while a new front end is designed in .NET/StrataFrame. Meaning, VFP tables set up as linked servers in SQL, and those tables are not as neatly set up for BO mapping as I would like.

Coming from a VFP cursor based development methodology, I'd appreciate links and white papers that'll help me start off with a solid StrataFrame data object model.

But, this thread is 3 years old, have any advances been made to the SF BO model?

Thanks.

Bill


Tags:
Post #29468
Add to Twitter Add to Facebook
 Posted 1/30/2011 2:30:27 AM
StrataFrame User

StrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame User

Group: StrataFrame Users
Last Login: 11/7/2018 2:37:04 AM
Posts: 193, Visits: 9,066
Hi William,

Why do you want to set your VFP tables as a linked server in a SQL Server?
I'm working on VFP linked server in SQL for 2 years whith the french VFP MVP, and now we know for sure that VFPOLEDB is not full compatible with the requirements of a linked server (many many errors with the PK and cdx, erratic management of the RI, management of NULLs is a monstruosity,...).

Simply map your StrataFrame BO on your VFP tables. It runs fine, with no errors. You may have an app with both VFP and SQL connection, i.e some BO are VFP based, and other one are SQL based.

You have the requirement to use the current database schema? where is the problem? you used it in VFP app, use it in SF app. Consider a SF Business Object as a super-VFP cursorAdapter Class, with enhanced PEM model.
Post #29469
Add to Twitter Add to Facebook


Similar Topics

Expand / Collapse

Reading This Topic

Expand / Collapse

Site Map - Home - My Account - Forum - About Us - Contact Us - Try It - Buy It

Microsoft, Visual Studio, and the Visual Studio logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.