1) If the DB name has spaces in then the class generated includes those spaces and therefore won't compile - easy enough to remove them but thought it worth a mention
Ah! Thanks, hence the reason for "testers". I never use spaces within column names.
2) The class summary comments - it currently shows something along the lines of "/// The 123Whatever table" which is the cleaned up version of the table name rather than "the 123 What ever table" - I'd just use the "source" name here rather than running it through the esPlugin.Entity() method.
I have to consider this carefully along with with your #1 comment from above. For me, the table names are used as the core of what ES uses for naming ES classes. The primary purposes for building this "helper" is:
1: To assist with building ES queries in a disconnected fashion. For example, there is a table "Categories" in the Northwind database. ES will build "Categories", "CategoriesCollection", "CategoriesQuery", etc. I dynamically invoke ES based on selecting an available "table". If I use a core name that differs from the core named by ES, nothing will invoke properly. My initial thought is to corrct your #1 comment above to "cleanup" via ES and add another property (if its not there) that would refere to the "RawTableName" or DatabaseTableName".
2: To assist with discoverability. I make sure that all possible properties are always referenced to eliminate confusion. For example, even if certain properties don't apply, I have values available and specify what values indicate they are not used in the comments so that a user doesn't run into properties appearing and not appearing for each respective table and sub-properties. If no foreign keys are defined, the class will still be created without any properties. The user will always see a reference t foreign keys for every table.
3) Your references to ES names (especially copyright notice)
I will correct what you identified - I agree. However, I will still leave a header that defines the ES assemblies versions, etc and still reference ES. There is no questionthat te helper is designed specifically to be inter-related to ES objects. It is not designed to be totally independant. Again, as I desribed above, the naming must match ES naming conventions because the values are sued to dynaically invoke ES objects. I know that i I pass in the correct name for "Categories" for the Northwind dtabase, that I can dynamically invoke the class "CatgoriesQuery".
I will clean this up and continue on the Query Builder. The first version will not support sub-queries or "IN" statements. Once the simple queries are working, I am hoping to add support for more advanced queries and eventually support them all (if possible).
BTW: I am sure users will like having a VB version. Thanks for that!
ALSO: Do you (or anyone) know if you can get the SQL generated from an ES query WITHOUT actually having to RUN the query? I want to have the Query Builder be capable of outputting the SQL and the equivelant Code besides actually running the query and returning the results.
TIA