>I just got use to the idea of entities being associated with business objects, and now the DevGuide refers to free-standing entities.
>
>Why would you have a free-standing entity not associated with a business object? In what circumstances might that be useful? Is it anything like an in-memory DataTable that's not connected to a database?

I've used this in web apps when I want to be able to easily validate data w/o actually having to hit the database. The scenario is usually a page where a user can add a new record and just clicked on a Save button. Previously, you'd have to hit the database to retrieve a new Row object (which the Entity) was bound. At that point you could then validate the data. If the validation fails, you throw away the row and display the error message. Essentially, you end up with a database hit each time, even though it's not really required until you do the save.

Another place where I've found this helpful is to just be able to pass around "sets" of data in places where you might just use a structure instead. Again, this seems to usually come into play (for me, at least) during validation scenarios. For example, a business process that involves multiple business objects. I really don't want to have to keep hitting the database for an operation that may eventually fail anyway, because of validation errors (or do things like begin a database transaction and THEN run what could be complex validation rules inside of that transaction). You can group the expensive operations together and then just run the insert/updates when you're reasonably sure they'll be successful.