I have a form with few tabs, and in each tab an grid control. When user select a row to be deleted i want to remove it from the grid, and if the object exist in the database remove it too, but not permanent – only if and when user clicks save on form.
For now, if object doesn’t exist in db i remove it from the list, and if objects exist in db i delete it from db and remove it from the list. But, if user clicks Cancel button he expects row/s not to be deleted from database.
I have two possible solutions on my mind: 1) – remove object from list, and if objects exist in db add it to the list of objects to be deleted 2) – implement another list, getter will return only objects with state != ToBeDeleted (performance?)
Note: i’m not using ORM tool, working with my own ado.net based data access framework.
I think the case you are descibing just asks pretty much for a Transaction.
ADO.Net handles them easily, provided you are using a reasonable database engine (so: no SqlServerCE for example:))
See for example the TransactionScope class. You construct such object before interacting with the database, and the changes will be “commited” if and only if you call Complete(). If you just leave it alone or if you Dispose() it, the transaction will be cancelled and all changes on the DB will be “rolledback”, so, reverted.
So, in your case, you may open the transaction in the Form’s ctor or onLoaded(), and Complete() at “save”, and Dispose() at any other window closing.
While this is the normal way of handling such things for small systems, especially single-user ones, but be careful: if your system has to handle many concurent useres, you may be not able to use it in this way. The Transaction blocks rows and tables until it is completed or cancelled, and the therefore “other users” may see large delays..
So, how many users do you have to support and how often they will try to edit the same things?
— edit: (10 users)
With that many users, you will want to avoid long-running transactions. Opening transaction at form-load will be unacceptable, and will lock many users away until that one current user closes the window. But, using transactions at Save() that push all the changes in one batch are OK.
Of course, if you can eliminate transactions at all – that’s great! But, it is very hard thing to do if you also need to preserve data integrity.. To eliminate the need of transactions, almost always you have to redesign both the data structure on the DB side, and the way you obtain and work with the data. If you want to redesign both, then I’d really recommend to first try redesigning it to use some existing data-access framework, as even the basic .Net ADO has really nice features for online editing of databases held at SqlClient-compliant databases..
So, assuming you don’t want to rewrite/rethink most of your code, you just need to buffer the data and also, delay all of the actual operations on the database.
You may want to do it in a “simple” form: when you display your form, instead of binding your Form directly to the database-driven datasources – download all required data to some BindingList<>s, DataTables, etc – whatever container you like. And bind your form to them instead. Probably you have something like that already set up. But, the important thing is that all those datacontainers must be offline or at least readonly+delayloaded.
Next, you’ve got to intercept all operations that the user performs on the UI. Surely you have it done already, as I’m assuming the application works:) As your Forms are bound to that offline cached items, your application should perform the operation on that cached data, and don’t touch the database at all. But there’s more: along with performing them on cached data, you should record what happens to which table.
Then, when finally the user stops playing around and presses CANCEL 🙂 – you just trash everything and close the form. database not changed.
On Save – you open a fresh transaction, then iterate over the list of changes and effectively replay your recorder changes on the database, then commit transaction.
Please note two things though: the database could have changed during the time the users cached the data and the time he pressed Save. You have to detect this and abort, or resolve conflicts. You should do that inside that transaction, either during or before executing the recorded changes. You may detect it by simply comparing the online data with offline cached data (the unchanged original values, not those modified by user), or you may use some other mechanisms like OptimisticLocking and just compare the version tags on the rows.
If you don’t like record-replay, you may implement a “DIFF”ing utility that takes the modified offline data and compares it in a generic way with the current-online tables. This is somewhat harder, but has a bonus: with such utility, you can initially doubly-cache the data: one copy for offline reference (just stored and never touched by the user) and one copy for offline editing (all those bound to the Forms). Now, upon Save you open transaction and diff the reference data against the online database. If there are any difference – you’ve just detected a collision. Solve/merge/abort/etc. If no differences, then you diff the modified data against online-data, and apply all differences found to the database and commit transaction.
Either of those methods has its pros and cons: aside from difficulty of implementation, there’s memory issues of caching, latency issues if you dare to copy too large tables, etc.
But – once solved, it would work pretty nice.
And as you finish, you can go and boast that you have just implemented a smaller sis’ of the DataSet+DataTable. I’m not joking, and I’m not laughing at you. I’m just trying to show you why everyone is telling you to rewise your DAO layer and try understanding and using the hard work that was already done for you by the platform designers/developers 🙂
Anyways, I’ve said you can avoid the clashes and transactions at all if you rethink your data structure.. For example: why do you DELETE the rows at all? I know there’s a nifty DELETE statement in the SQL, but, well, do you really need to delete that row? Can’t you just add some ‘bool isDeleted’ column and when user deletes the row from the Grid – just make set that rowcell to True and make the application filter-out any isDeleted=true rows and not show them? and not include them in views and aggregations? Bonus: sys/db admins now have a magic tool: undelete..
Let’s take it further: do you need to UPDATE the rows? Maybe you can just APPEND some information that from (this-date) that row should have a new price? of course, the structure must be greatly altered: entities doesn’t have properties, but have logs of timestamped property changes (or either the rows must have version numbers and be duplicated..), queries must be done against only the newest versiosn data, etc. Pros: database is now append-only. Transactions, if needed at all, are hyper-short. Cons: SELECT queries are complicated and may be slow, especially when joining many tables..
Pro/Con: and your db actually starts looking very meta- instead of data-base…
Con: and this is really hard task to “upgrade” existing application to such db structure. Writing a new app from scratch and importing data from odl system may be few times faster.
Now, to summarise:
..and of course yo umay use long-lasting transactions. Dumb-easy to introduce, and they “just irritate” the users.. Well, or even make the system unusable when >90% of the users constantly collide and hit the locks, heh.. No, that was a joke. Don’t use long-lasting transactions. They are ok for 1-4 users, or for very sparse databases..