Hi, I've got a simple situation where a collectgion is bound to a datagrid, and one major benefit of the memory based collection is that it is effectively transaction based because no changes are written to the database until I call MyCollection.SaveMulti().

But is there any built in method by which deletion requests against the collection can also be simply handled? It clearly makes no sense for the object to perform the database deletions at this point, but is there a built-in method by which I can record which were 'virtually deleted' and delete them afterwards?

If there isn't anything already defined in this way, would it be feasible to have a 'TrackDeletions' property and something like a 'RemoveForDeletion' method that removes the item from the collection but adds the key to a 'DeletedEntities' collection. You could then simply loop through the 'DeletedEntities' collection handling them (such as deleting them) as required.

I know that this could be implemented separately in code, but the code base to implement simple database maintenance functions via grids is so short and tidy in LLBLGen that it seems a shame to make it complex by adding extra collections in the codebehind.

Cheers, Jason

A few more questions relating to this issue...

Is there any reason why the BeforeRemove method doesn't indicate which Entity is about to be removed? Could the entity be passed as a BeforeRemoveEventArgs parameter? Also, is there any situation under which the removal might fail? i.e. Should this actually be named 'OnRemove', or ought there be an 'AfterRemove' to indicate whether the removal succeeded or not?

Is there any means of passing a Collection to the DeleteMulti functions and having these treated as a set to be deleted? My code to support deletion in the grid is something like:

        AspectCubeCollection deleted = new AspectCubeCollection();

        private void Cube_Maintenance_Load(object sender, EventArgs e)
        {
            aspectCubeCollection1.GetMulti(null);
            this.CubeGrid.DataSource = this.aspectCubeCollection1;
            aspectCubeCollection1.BeforeRemove += new EventHandler(aspectCubeCollection1_BeforeRemove);
        }


        private void btnOK_Click(object sender, EventArgs e)
        {
            aspectCubeCollection1.SaveMulti();
            foreach (AspectCubeEntity ace in deleted)
                ace.Delete();
            Close();
        }


        void aspectCubeCollection1_BeforeRemove(object sender, EventArgs e)
        {
            AspectCubeEntity ace = (AspectCubeEntity) CubeGrid.CurrentRow.DataBoundItem;
            deleted.Add(ace);
        }

It would be nice to remove the reference to the grid control (hence why the Entity parameter would be good), and it would be even nicer if there was the feature where these deletions were tracked internally so that an overloaded SaveMulti() method would also perform the appropriate deletions.

This is my first serious application using LLBLGen, so I'm keen to know if I'm approaching this the right way.

Thanks, Jason

The sender parameter is the entity being removed; just cast it.

Typically in the adapter scenario you would add it to a unit of work and later commit that to the database. For example:

        private void BeforeRemove(object sender, EventArgs e)
        {
            uow.AddForDelete((IEntity2)sender);
        }

I haven't used self-servicing so long I'm not so sure if you would handle this eactly the same way. Also, I don't think there's any real reason why removing the entity from the collection would fail.

Please use Jim's answer, and for further info on the UnitOfWork please refer to the LLBLGen Pro documentation "Using the generated code -> SelfServicing -> Unit of work and field data versioning"

Thanks Jim, I assumed that the Sender would be the Collection, as this seems to be the standard in .NET, rather than the Entity. I finally found a description in the Reference Manual documentation.

If this is the case, then this introduces another problem. If the same event procedure is handling multiple collections, it is not possible to know which collection has generated the event (hence why Sender is usually the event generator). So, once again, should we not have a BeforeRemoveEventArgs parameter added?

Walaa, I did already read the UOW documentation, but felt it overkill for the purpose of handling a simple collection in a grid. However, are you suggesting that instead of my existing approach, I associate a UOW with each Collection, call UOW.AddForDelete in the Collection.BeforeRemove event, then instead of calling Collection.SaveMulti(), I call UOW.AddCollectionForSave then UOW.Commit(...)?

I believe this process of simple grid data management is a very common task, so it's almost certainly worth including some examples in the 'Using the Generated Code' section of the help manual.

Cheers, Jason

At the moment, there are cases where you'd like more events in the code. These are planned for v2, as it might be that we've to alter current events or make them obsolete.