|Dynamic Query Engine: When I read the article ADO.NET v2.0: ObjectSpaces Delivers an O/R Mapper I also got a confidence that Microsoft is also going in similar directions. The hardest change for me to grasp was that LLBLGen Pro uses a dynamic query engine that generates queries on the fly allowing high level object oriented commands to replace stored procedures. As one that uses SPs exclusively this made me very nervous. After reading many threads about how the Java has been doing this for years, and that there is a move away from SPs in process for many reasons including performance comparisons merging with the ability to support many databases. Consider the case were a table has many fields of interest. You want to filter on any combination of these each trip to the data. In this new world you do not have to write many SPs, but simply instantiate a Sort and Filter object and use them in a dynamic query. Because of this the LLBLGen Pro can now support SQL Server, and Oracle versions and has more databases planned for near future. LLBLGen Pro can be applied to a project with SPs in stream since it will support the SPs that currently exist.
Entity classes and Typed lists: In the open source version there was one class generated for each table and if you looked at the code it made immediate sense. In the Pro version, each table gets base class, derived class, data class, validation class, etc depending on the generation configuration you choose. The code in these classes is not immediately obvious, but the interface is simple. Validation classes are separate so they never need to be regenerated and you do not lose your customizations to the validations. Typed lists are basically entity fields selected from related tables allowing construction of business entities and facade like classes within the gui form. There is a lot of potential here for one class for each screen, and one class for one transaction etc. When you need to add a field to a database table you will regenerate that class, but only the base class will be changed. Since your custom methods and properties are in a derive class or sub class of the base you never lose any code due to regeneration.
Collection Class support: If you want to work with a class directly (not in context of a parent class), you get a strongly typed datatable. If there is a relation between customer and order in your database, then when you want a customer 1 to many order screen with only the orders for customer 9330, you execute the following 3 lines of code where 9330 is the primary key id:
Dim customer as New CustomerEntity(9330)
orderGrid.datasource = customer.orders
Further lazy loading capabilities allow you to load customer object instance without loading all orders for that customer, and all detail order lines for each order, and all shipping addresses for each order, etc. Then as soon as you access the customer.orders.details the details fill in for the orders if they are not already loaded from the database. Further, a partially dirty/changed collection of details of an order can be sent with one method in batch mode back to the database for one shared repository update so other threads see all the pertinent changes at once. The classes know whether an insert or update is the proper thing to do so you can just do customer.save() Further, if I have a reference to an Order, I can get a reference to the customer of that order by simply referencing order.customer.
Binding Support: Classes will truly bind to web/windows forms due to change events built in to the entity classes.
Transaction Support: If no manually created transaction is presented, one is wrapped around your class.
Extension Support: An SDK is currently available to customers for changing the features of the program.
Deployment Support: When you generate, there is a .NET project file created that made it easy for me to add this project to any solution. Then I added a reference to that project from my main project, added imports statements on each page for the main areas and was off an running using the classes. (watch out for field names in tables that are VB keywords since that won't be handled automatically by the generator)