One of my pages contains a grid that is bound to a typed view, where I added an unbound checkbox column in order for the user to check which rows they would like to add or delete. Basically, when the user hits the save button, I need to loop through all the grid rows and figure out which ones are checked, which means I need to insert a record into some other table, and whichever ones were are not checked, go ahead and delete the row from the table. I'm using a typed view because I am pulling data from multiple database and making sql function calls in the query, so I am not able to bind the grid to an entity collection. I'm trying to figure out which Save and Delete adapter methods to use in this scenario. For my adds, I could either loop through the checked rows and create a new entity for each row and save them independently. Or I could also loop through the checked rows and build an entity, add it to an entity collection, and invoke a SaveEntityCollection().

Now, for the deletes, I could either delete each entity one at a time, or I could create an entity for each entity to delete, add it to an entity collection, then call the DeleteEntityCollection() method. Also, I think my last option would be to call the delete directly against the adapter, where I could build my predicate expression with all the id's right in there: (DELETE FROM tbl_MyTable WHERE (ID = 0 OR ID = 1 OR ID = 2...)

Anyone have any ideas on which route I should go with?

Thanks!

For deletes, use the direct route, DELETE FROM Table WHERE Id IN (1, 2, 3, 4) thus use adapter.DeleteEntitiesDirectly() and a FieldCompareRangePredicate which you create using an arraylist with possible values

For the save, I think the best way is to create new entities and store them in an entity collection and save that in 1 go, not recursive.

Otis wrote:

For deletes, use the direct route, DELETE FROM Table WHERE Id IN (1, 2, 3, 4) thus use adapter.DeleteEntitiesDirectly() and a FieldCompareRangePredicate which you create using an arraylist with possible values

For the save, I think the best way is to create new entities and store them in an entity collection and save that in 1 go, not recursive.

Perfect, thanks! I completely forgot about the FieldCompareRangePredicate.

Also, the more and more I go through and learn the LLBL architecuture and engine, I must say you did a great job of applying design patterns! It's not always so obvious when reading literature regarding a design pattern and its intent, when in the real world it can be applied.

MarcoP wrote:

Also, the more and more I go through and learn the LLBL architecuture and engine, I must say you did a great job of applying design patterns! It's not always so obvious when reading literature regarding a design pattern and its intent, when in the real world it can be applied.

Well I tried to include a lot of patterns, but it sometimes gets in your way as well: for example I implemented the DTO pattern with the EntityFields being filled for an entity. This was a bit of an overhead thing.

Frankly I'm not that in favor of 'patterns' as is. They're great when you have a problem and need a solution, but when you start with the patterns, you're often in for a lot of problems. Nevertheless, the GoF book was a good read

(and after you've read that book, you suddenly see that .NET is also full of patterns, as you said, it's not always so obvious )