This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello! I've spent the last couple of days researching LightSpeed and various other solutions and I had a question regarding its use. Is it for me? Before you can answer that I'll provide you with a bit of background information on our application. Background Our current application originally designed in the mid 90s is essentially a C++ database CRUD application with a variety of objects ( I won't use our specific objects, rather trivial examples ) such as books, publishers, authors, citations, etc... which the user can view and manipulate. The application allows users to manually update/commit data; that said a user connects, views all the books, modifies a few, updates their local view to see if other books have changed, and ultimately commits their changes to the database. There are tables which represent objects ( i.e. books, authors, and publishers tables ) along with static domain/lookup tables that provide selections to the user (i.e. countries ). All that being said I finally have the opportunity to bring this solution into the .NET world from C++. Current Concern with LightSpeed The concept of Unit of Work seems a little limit in scope to the current way users operate the application. Certainly the way the application currently operates ( manual updates/commits ) might be the issue but does Lightspeed lend itself to application where a typical database session may last anywhere from 10 to 30 mins before a user commits their data? In closing, I am extremely impressed with LightSpeed and I certainly hope I can integrate it into my .NET solution Matthew |
|
|
There are a couple of ways of handling long-running sessions in LightSpeed. The first way is simply to use a long-running unit of work. Everything gets batched up in the LightSpeed UOW, and when the user wants to commit their changes, you call SaveChanges() and it's job done. This is very easy to work with, but can cause problems: for example, it holds database connections open which could cause scaling issues, and it's not easy for the user to see if changes have been made by other people since they first looked at an entity. This latter issue is problematic for your use case of "user updates local view to see if other books have changed." The second way is to use multiple short-running units of work, and have users work with disconnected entities. So the pattern is something like "create unit of work, load books, close unit of work, make changes to books, create new unit of work, reload books, copy changed books into new unit of work, save changes." This is a bit more fiddly to work with, because of the additional step of copying changes into the new unit of work. You end up needing to manage your own batching to some extent: remembering which entities have been added, changed or deleted so that you can replicate those changes into the new UOW. LightSpeed does provide a way of iterating the entities in the old UOW which should help with this though. We generally recommend the short-running unit of work pattern and JD has written more about using this in a rich client environment here. Hope this helps -- let us know if you need any more details or have any further questions. |
|
|
Hi Ivan: Thanks for the link to the article it contained some great information. I do have another question regarding UOW and retrieving entities. Continuing with my above background example, if during a UOW a book entity is retreived, the user modifies the book entity, a new UOW is created how do I associate the book entity with the new UOW or is it something as simple as uow.update(book);?
Matthew |
|
|
I think I found the answer to my question, attaching the book entity to the new UOW via the IUnitofWork.attach method as discussed in the help should do the job.
|
|