I need some suggestions with solving a problem related to working with files and CSLA.
Many software solutions today offer a document repository system. Typically, during setup a shared directory is specified so that all end users can create and read files from a central location. After a setup directory is specified, users can create attachments for Customers, Projects, etc. I was modeling Attachments as being a child collection of Customers, Projects, etc. So if the end user is in a Customer screen, there would be an attachments tab where the user could open, add, and delete attachments for that specific customer.
So heres my problem. Typically, when a user creates an attachment, the file is sent directly over to the shared directory. However, because the attachments sit in a disconnected state from the database until the Save method of a Customer is called, the user could queue up a bunch of attachments and then choose to Undo all of the changes... leaving X-Amount of files on the file server with no corresponding records in the database.
I have come up with a few potential solutions, but each has some sort of logic/usability flaw.
#1. Each time a user creates an attachment, force the Customer object to Save(). Flaw: All undo capabilities are lost for the customer business object.
#2. Add a property to the business object to store the local path of the file, and when the Save() method is called on the child attachment object, do a file operation to copy from the local path to the server path. Flaw: If a 3rd physical tier is being used for the data portal, the local file directory no longer exists (its still referencing the smart client's file path).
#3. Same as #2, but instead of holding a file path in the attachment object, store the actual file in a serialized form (byte array or something). Flaw: If they change the file after they've created the attachment (BUT BEFORE ITS SAVED), the file being held in the attachment object is no longer up to date.
#4. Save the files in the database directly. Flaw: Database performance.
I'd really appreciate if someone could throw some ideas out at me. Thanks in advance!
Your scenario is a long-running-transaction scenario. Even a transactional file system (which may come in Longhorn I guess) won't help you, because you are storing these files on the server over a period of time, clearly outside any form of tightly coupled transactional context.
So the solution to a "rollback" in a LRT scenario is to use a compensating transaction. In other words, if the LRT fails, you need to implement code to manually roll back what's been done.
I'd suggest that you consider using a service to store the files on the server, rather than storing them directly to disk. The service, running on the server, can store the files, but it can also keep track of the fact that they aren't "real" yet. It might even store them in a temporary directory at first - that's up to you, but it would be a decent answer.
Each of the files you store as part of one LRT would need some "transaction id" or "session id" associated with them so the service knows that X files are all part of the same LRT. At some point later, if the user invokes Save() on your object, the DP_Insert or DP_Update method can call the service to tell it to commit all files for the specific transaction id. At that point the service knows that the files are "real" and can do appropriate work.
If the user abandons the session (workstation crashes, etc) the service would need a timeout. After N hours it gives up and implements a rollback (deletes the files for the transaction id). You might allow that same mechanism to handle the user-never-saves scenario too, especially if the files are in a temporary directory until they become "real".
Or you may choose to override UndoChangesComplete in your object and notice when the editlevel reaches 0. If that happens you know the user has canceled back to before the files were added and you can call the service to tell it to do a rollback.
Copyright (c) Marimer LLC