Thank you, Trent. I do see your point, to avoid grid-central design, but in this case I'm convinced that this is the way to go due to the built in, drag-and-drop grouping and sorting functionality, filters, etc. The application that I'm trying to develop is just a small module of a future redesign of our LMS software. If I'm successful in implementing this with SFBOs I'd go on to use SF platform for all our future development. So I'll need all of the 747, peanuts included 

Thanks for your interest in StrataFrame.  As you well know, there are a lot of philosophies in application development, and many times there is more than one way to skin the proverbial cat.  First of all, you would bind using a BusinessBindingSource to the grid.  This provides direct multi-row .NET data binding and is the most appropriate tool for binding to a grid.  Ultimately you would be able to manage your complex configuration.

As for the purpose of StrataFrame, I am almost not sure the best way to answer.  StrataFrame has so much depth and performs so many tasks that purchasing StrataFrame just for the purpose of binding to a grid is kind of like buying a 747 for the peanuts .

StrataFrame handles everything from the UI all the way back through to the DAL (Data Access Layer).  It also manages your relationships from an object model perspective and will even propagate this back to the database for you.  By defining your parent-child relationships, the BOs will automatically handle foreign key values and make sure that they are persisted.  So that is one of many benefits that would pertain to your current situation.

StrataFrame is designed to work with 3rd party tools, such as DevExpress, though when working with these tools and understanding the logic behind the 3rd party aspect, you will have to get support from the said 3rd party as StrataFrame users use so many different tools that it is not possible for us to be a support expert in each tool.

As I previously mentioned, there are a lot of philosophies in development, and one is...no offense here...not to be so grid complex.  We have some tools that make short work of parent-child UI.  To begin, our ListView in conjunction with a ChildFormDialog.  This is a quick and simple way to manage child tables with RAD functionality and is generally more user friendly in the end.  StrataFrame was created from our need to produce an extremely massive medical application.  We do use some grids now and then, but we have learned that leaning too heavily on grids can become an end-user issue but also a development issue.  In short, you can do just what you are trying with StrataFrame, but I would recommend taking a look at some other ways to tackle this problem as I think that you will have more positive results all the way around.

Again...this is just my opinion, but that is one great thing about this forum, we all share our experiences and opinions and come out the better for it...as does StrataFrame as we really try to listen!!!

Thank you for your answer. Unfortunatelly I don't see how this applies to EnhancedList. It is not groupped the same way as XtraReport is. Instead it uses relationships to set-up the GridView structure at design-time. One way suggested was to use DataSets extracted from BOs to do the binding. If I do that, why use strataframe at all? Using views, is also quite combersome, as it forces me to set up all the GridViews at runtime, as opposed to using the extensive features of the EnhancedList's Designer tool. Also I need my application to be able to add/update rows, which is risky using views.

Hi Lukasz.

Take a look at the posts from here, they can help you:

http://forum.strataframe.net/FindPost27721.aspx

Also, the BOs can represent a view. So if you build a view wich represents your join, you can just create a BO and map it to the view.

Hello,