The BusinessLayer class should provide the following abstract methods:

• CreateSelectQueryInformation()
• CreateInsertQueryInformation()
• CreateUpdateQueryInformation()
• CreateDeleteQueryInformation()
• CreateSelectStoredProcQueryInformation()
• CreateInsertStoredProcQueryInformation()
• CreateUpdateStoredProcQueryInformation()
• CreateDeleteStoredProcQueryInformation()

The implementing business object classes should return a new QueryInformation object initialized with the appropriate QueryType and stored procedure settings and all of the field and table properties already initialized based on the underlying data structure.

 

This would greatly simplify generation of QueryInformation objects when writing code and facilitate their use querying.

 

You can expose those methods by creating your own BusinessLayer class (that inherits from MicroFour.StrataFrame.Business.BusinessLayer) and returns the appropriate QueryInformation from the _DataLayer internal to the business object.  The query information objects used to save the business objects are created by the internal DataLayer object, not by the business object itself.

While what you stated is true, is assumes that developers will not use the FillDataTable(ByVal QueryInfo As QueryInformation) method.  Development best practices suggests that SQL statements not be embedded in source code due to differences in SQL syntax between RDBMS vendors.  Using the QueryInformation object to provide your WHERE clause information is a great alternative.  So, having methods that provide an initialized QueryInformation object would eliminate repetative coding to initialize many of the properties for which the data already exists in the business object. 

I agree that the Insert, Update, and Delete versions of these proposed methods might be of little use to most folks, but the select versions would be helpful for those of who see value in using QueryInformation objects in the FillDataTable() and GetDataTable() methods.

I just realized that there is no corresponding GetDataTable(ByVal QueryInfo As QueryInformation) method.  That would also be a useful addition.

Key word here being "suggests."   Here within lies the problem.  This type of functionality alone could become a full time business.  In fact, there are third party companies that have products that do nothing but act as in "go between" all database query types.  For example, if you prefer to "speak" in SQL Server, you create your queries in that syntax and if you need to have it spit out the Oracle, MySql, etc, then you just set an output property and the statement is altered to the desired language.

Though we will continue to add functionality to our QueryInfo class, we have never claimed, nor plan, to become a "full translation" company.  If you have this need, and you are planning on supporting several different languages, then you should search the internet for some of the 3rd party companies that have a translation product available or create your own class to meet your needs.

http://www.swissql.com/products/sqlone-apidotnet/sqlone-apidotnet.html

Additionally, with the advent of DLinq, this problem will ultimately resolve itself by removing all embedded SQL.  This will be a part of StrataFrame 2.0 (for use with .NET 3.0).

Thanks, I will look into that.