First, let me say that I have just begun exploring StrataFrame, so some of these observations may be the result of inadequate exploration or misconception... but here goes (my background is PowerBuilder, Delphi, many RDBMS's):

I really like the web site, the examples, and the StrataFram Help (especially the Getting Started stuff). I have created a simple single form / single Business Object WinForm application... so now I am an expert. <g>

Concerns (you had to suspect this would be the longer list... right?):

1) I question the idea of binding the Business Objects right to the forms. Why not bind a BO Proxy to the forms, and keep all the BO's in one container? I know there is some ability to Share Data... but why should this be a case by case implementation detail? In fact I would see this as something you guys already already addressed (at the macro level) with the Enterprise Server alternative to the Client Server approach of connecting each BO directly to the database. IOW, why would you want each form in an application have its own (Customer) BO with a private buffer... out of synch with each other form/(Customer) BO/buffer in the application?

2) There is a loud "silence" on the WPF/SilverLight front. Along these lines, there seems to be a bit of a hush over when the next maintenance release will appear... and what will be in it.

3) The use of "Select *" in the example SQL statements. Generally we remove the fingers of developers that do stuff like that. I'm not sure how your BO's react to changes in the database tables (renaming columns, changing data types, adding/removing columns, etc.). We find explicit column references helps us find the issues pretty quickly. Along this same line is the missing ability to Auto-Generate bound controls based on a Buisiness Object (or actually BO Proxy <g>.

4) There doesn't seem to be any system level caching capability.

5) Almost all the Help examples are in VB, which doesn't help a C# newbie.

6) And finally, why do the C# samples contain reverences to a VB construct...
//-- Forcibly close the application to stop message pumps from looping and preventing the application
// from closing
ProjectData.EndApp();

Hey (Note: I've been living in the South for quite a while) Ben. Thank you for the response... my comments inline

1) It was a design choice.  It was determined that since not every form within an application needs the same data, it was simpler to engineer a way for forms to share what they needed (through SharedDataTableKey, ChildFormDialog, etc.) rather than to have all forms share the same data.  More often than not, we found that each form actually needs its own data.  I.E.: Our medical software has "folders" for patients; each patient has its own folder and you can have several folders open at a time.  So, since each patient is completely independent, there is no need for them to share the same data... they each need their own.

While the detail data shouldn't be shared, the "list" data should... and should be consistent everywhere displayed. Perhaps SatredDataTableKey gives me what I am looking for, not sure at this point. BTW, the documentation on ChecldFormDialog talks about BO "translation"... but I haven't seen that explained.

2) I would not go so far as to say "silence."  If you go to several of the websites of control designers in the .NET market, they all say that they are working on WPF controls, but until the design-time support is at least Beta 2 or RTM, they're not going to release them.  The only thing our business layer needs is the implementation of one more interface to enable the functionality to tie to WPF (INotifyCollectionChanged... the same thing that ObservableCollection implements).  Additionally, since our business objects can already attach to anything that accepts IEnumerable as the source (ItemsSource, DataContext, DataSource, etc.), you can certainly use a BO with WPF right now.  As for design-time support within WPF, we're not going to support it until it's RTM.  StrataFrame was not released until VS2005 was RTM, and our support for .NET 3.0/3.5 will not be there until the design-time support is RTM as well.  If you're wondering if all of our business objects are going to be DependencyObjects and have all of the fields as DependencyProperties, no, we are not; they will continue to be regular CLR objects.

Posting what you just said on the Web site was exactly what I was looking for.

As for the 1.6.1 release, it's coming soon, but quite frankly, we don't want to pin a date on it as requests from the forum keep working into the release.

You could expose the list of what is already there... and keep adding to it. That would keep everyone informed. I asked because I saw others requesting the information... and the last entry in Posted Releases was from February (it was however this year ). 

3)   I agree with that.  That's why there is a property called AllFields on the business object that returns a string of all fo the field names.  Same for the TableNameAndSchema property that returns the table name and schema so, you could use "SELECT " + this.AllFields + " FROM " + this.TableNameAndSchema and you would avoid the use of the * you vehemently dread.  However, not all developers are like you, so we certainly have to still support the *

"Select *" is valid SQL, so you should support it. You didn't mention what happens to the BO classes when a column datatype is changed... or a column is removed. Does this cause design time errors... or runtime errors?

4) No, there isn't.  We have created a semi-caching engine that caches single records based upon the PK but until we are happy with it, we won't include it in the framework.  You certainly have the ability to create a set of static BOs somewhere with all of your lookup tables... since that's the thing people generally want to cache.

Which is one of the reasons I asked Question #1. Properly sharing one instance of well-cached reference data is a very important piece of functionality. An just like "idiots being so damned clever" (in the sense of idiot-proof software), I've alsoways found "static" reference data to fall well short of static. But then again I don't expect a Framework to solve all my development problems... but I remain optimistic.

5) Yes, all of the original samples were in VB and are in the process of being reworked to include both.  New help includes both.

No problem.

6) Well, that's because we had tons of VB samples and we wanted to have the same ones in C#.  The quickest way to do so was to run them through a converter, so, that's why some of them contain the C# equivalents of things like the With keyword in VB.

For your consideration: If you reley on a converter to produce code that is reviewed by potential customers... they may judge your coding (and design) skills by what they see.

Regards,
Mike