Updating using linq
In addition to saving a trip to the database, you also have a method for performing batch deletes.
The Delete method itself, by the way, returns an integer result that tells you how many items were deleted (which might be more than one because, after all, there might be multiple customers whose first name is Peter).
And, as I've discussed in more recent columns, you can simplify your code and optimize your client-side data access by separating your data retrieval code from your update code (the CQRS pattern). E library actually includes four more-or-less separate sets of functionality, but, for me, the jewel of the crown is the library's support for batch updates and deletes without data retrieval (I'll discuss one of the other sets in a later column). NET directly to issue this command, you make just one trip to the database to send the statement (after, of course, fussing around with Connection, Command and Parameter objects).
As a result, I've been writing columns on how, exactly, you could implement all of that using the base versions of Entity Framework and LINQ. If, on the other hand, you use Entity Framework and LINQ (I'll call it EF LINQ) to manage your ADO.
If you let EF LINQ mange the process, on the other hand, you'll first have to retrieve all the Premium Customer rows and then iterate through all of the resulting objects, updating each one individually.
And, you'll note, at this point you haven't even called Save Changes, but you've already made one trip to the database.
You'll still only make one trip to the database on the call to Save Changes because Entity Framework will bundle up all of the Update statements into a single transmission wrapped inside a transaction.But, in one of those columns, a reader pointed out that I've ignored an open source set of Entity Framework extensions that makes it easier for you to achieve that separation: the Lore Soft Entity Framework Extended Library (available through Nu Get as Entity Framework. NET code and generate your SQL statement, the default pattern is different.With EF LINQ you retrieve the corresponding object, remove it from its collection, and then call Save Changes.However, each of those potentially unlimited number of Update statements will be executed individually because there's no way for the database engine to optimize these updates.If you have a lot of Premium Customer rows, you'll have an operation with a response time that should be measured with a calendar, not a stop watch (assuming that your application doesn't just time out waiting for a response).