In my last article on this topic I discussed how I found it easy to modify the LLBL open source version to use my Data Access Layer. Since that time I have made many modifications to make the LLBL faster to use by automating the regeneration process to copy right over my source classes, but saving my custom methods in a region called Custom Methods. I was building in isvalid and isdirty properties when I looked at the Professional version. I found it to have every advantage I had added and many more that made it crucial for me to look into it more. Its $200 cost made it very attractive also. (See link at article end for demo download and more info)

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


orderGrid.databind

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)