Hi all,

Not sure if this is the right place to post this question but I only have the trial version at the moment (will definately purchase if I can understand the following!) and wasn't sure where else this type of post might go.  I have been playing for about a week now and seem to have the hang of the basics by using the examples provided (which are excellent I might say).  However, been new to OOP, I have no idea why I am using one object over another and as such, was wondering if someone might help with a short description (maybe a basic example if you were really keen) of when one object might by used over another.  Using the Northwind Employees table as an example, under what circumstances would I use the following; EmployeesCollection, Employees, EmployeesQuery and EmployeesMetaData?

I appologise if this is already detailed either in documentation or the forums, but I can only seem to find passing references to the information I am after.

Thanks in advance :-)

Wade.

• EmployeesCollection - You use this whenever you want to deal with more than one row of data at at time. An EmployeesCollection object is actually populated with Employees (the single entity class). When saving data via a collection you can call Save and it will save all inserts, deletes and updated automatically within a transaction
  
  
• Employees - This is the same class that is used to represent data in a collection. However, it can also operate on it's own (outside of a collection). However, there is one rule, it can only represent a single row of data. So, you can use the Employees class to load a single record, modify it, and save it (or delete one, or create a new one and save it)
  
  
• EmployeesQuery- This class is used whenever you want to create a dynamic query using our super cool query syntax to load data from the Employees table. Both the EmployeesCollection and Employees object have an inherit instance of this class on them, so you can access it this way coll.Query or entity.Query. However, in our next relase (see our latest blog post) you can even execute Query's that are not part of a collection or entity. However, for the most part you will just use the Query built into the collection entity classes as our samples show. Then can get pretty sophisticated with Joins and such as shown on the home page (and blog with subqueries and such).
  
  
• EmployeesMetaData - You basically don't every really use this class. However, there is an exception. Anywhere that you would normally hard code the name of a database column or class property you should use the EmployeesMetaData.Columns or EmployeesMetaData.Properties listings. In ES you can alias a column to give it a nice property name, thus the two could be different. By using the EmployeesMetaData "names" you can rest assured that you will get a compile error if you rename or drop a column rather than a runtime error. However, you really won't use these that often.