Author |
Share Topic Topic Search Topic Options
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009
Location: Dallas, Texas
Posts: 343
|
Post Options
Quote Reply
Topic: Multiple EM best practices Posted: 08-Jan-2010 at 9:17am |
Since seeing the Billy Hollis WPF demo, I have really liked the idea of
allowing the customer to have multiple edit forms open at any one time. With a single EM that would be quite dangerous, and
impossible to manage.
What are the best practices for achieving that?
My thoughts were:
- Global EM that contains all the data
- When an edit form is opened, create a new EM and import the data that
you need
- Upon save, import the saved entity back into the global Entity
Manager, so the changes can be seen by all. On any other action, simply
discard as it is of no use.
Thanks,
Mark
|
 |
GregD
IdeaBlade
Joined: 09-May-2007
Posts: 374
|
Post Options
Quote Reply
Posted: 08-Jan-2010 at 4:24pm |
I did a multi-EM solution a while back in DevForce Classic, and used a design similar to what you have described. - When an edit form is opened, create a new EM and import the data that
you need
Of course the needed data must first be retrieved into the main EM, then imported from there into the local EM
- Upon save, import the saved entity back into the global Entity
Manager, so the changes can be seen by all. On any other action, simply
discard as it is of no use.
I don't think you would discard it on "any other action"; but rather, when the user explicitly indicated that she wanted to close the form and discard any changes.
Note also that it's likely to be multiple entities that have been changed and are being saved, so it is those that you would import into the main EM from the local one. Then you would immediately execute a save of all modified, deleted, or new entities in the main EM.
An additional issue to think about is whether you want individual forms to be notified of changes made (and saved) from other forms. For example, a Customer form and a SalesRep form might both display Orders (those placed by the Customer currently being viewed, and those written by the SalesRep currently being viewed), so you might have the same Order displayed on both forms. If updated in one, do you want the copy in the other to be refreshed with the new values immediately? This gets a little trickier to write, but could be done.
|
 |
erturkcevik
Groupie
Joined: 14-Jun-2007
Location: Turkey
Posts: 40
|
Post Options
Quote Reply
Posted: 11-Jan-2010 at 1:07pm |
More than one EM is used, Can you give me information about the performance? What should be observed in use in terms of performance?
Regards,
|
 |
GregD
IdeaBlade
Joined: 09-May-2007
Posts: 374
|
Post Options
Quote Reply
Posted: 11-Jan-2010 at 4:57pm |
That depends on how you write your code, but assuming you do a reasonable job with that, I wouldn't expect performance to be much affected. If you implement as I described above, then you will have at least twice as many entities in the cache (a local copy + a central copy of each entity) all the time as you otherwise would. But that's a memory footprint issue, not a performance issue. Obviously some extra time will be required for copy entities back and forth between caches. But the forms could see an improvement in performance because they'd always be interacting with a smaller cache than if you were using one cache for all of them. But overall, I wouldn't expect noteworthy change in performance in either direction.
I think the question should probably hinge more on the balance between the user experience that you want versus the difficulty of coding and maintaining a multi-EM solution versus a single-EM one.
|
 |
sebma
Groupie
Joined: 19-Aug-2008
Location: Singapore
Posts: 66
|
Post Options
Quote Reply
Posted: 02-Mar-2010 at 10:51pm |
I saw a mention of something like a "global" Entity Manager and keeping it up to date yourself.
Note: The EntityManager is not thread-safe.
|
 |
gkneo
Newbie
Joined: 23-Jun-2010
Posts: 21
|
Post Options
Quote Reply
Posted: 04-Aug-2010 at 2:57am |
Hi!
What about using :
public EntitySaveOperation SaveChangesAsync(IEnumerable entities, SaveOptions saveOptions = null, Action<EntitySaveOperation> userCallback = null, object userState = null);
|
So if you have multiple forms for creating/editing entities, you just call the above method with the current form's entity as first parameter (first get the entity into a new list). Is it safe to use or there are other things to consider? Regards,
Guilllermo
|
 |
GregD
IdeaBlade
Joined: 09-May-2007
Posts: 374
|
Post Options
Quote Reply
Posted: 05-Aug-2010 at 5:38pm |
The async methods provided by DevForce are thread-safe; and there's also no problem with having multiple EntityManagers all launching async queries, saves, and remote service method calls.
What you can't do safely -- unless you're very careful -- is to pass a single EntityManager around to separate threads. But again, the provided async methods typically address the use cases that might otherwise tempt developers to do that.
|
 |
gkneo
Newbie
Joined: 23-Jun-2010
Posts: 21
|
Post Options
Quote Reply
Posted: 05-Aug-2010 at 11:17pm |
Hi, understood. But what about using the above signature of the async method and sending only the current form's entity instead of having multiple managers? Imagine this entity has 2 navigation properties (one as relatedEntityList). If I add new items to the list and a new instance to the other navigation property, if I use the above method do I only have to send the main entity (and devforce will handle the navigation properties) or do I have to apply some code to look for all the navigation properties that are added/modified for the current entity?
I hope I made myself clear.
Regards,
Guillermo
|
 |
GregD
IdeaBlade
Joined: 09-May-2007
Posts: 374
|
Post Options
Quote Reply
Posted: 06-Aug-2010 at 7:51am |
You have two choices with the save: - You can tell the EntityManager to save everything that represents a pending change, or
- You can pass it a collection of entities to save.
If you do the latter, it only saves what you pass it. We have no way of knowing, in the case of a limited save, what a developer wants to save or not save. We could cook up an elaborate syntax that would allow you to tell us which related entities to include, and how far out along the chains of associations to go, but it's really easier and surer to give you complete control over the process. You build the collection, we'll save it for you.
|
 |