Read-Only entities with an editable treeview pattern

Read-Only entities with an editable treeview pattern

Old forum URL: forums.lhotka.net/forums/t/10684.aspx


crackity_jones666 posted on Wednesday, September 14, 2011

Hello!

We are working for quite a while on an editable Treeview (which include move and rename features) in silverlight using MVVM patterns.

We decided, from a scalability perspective, to rely on read-only entities to bind the treeview.  In fact, we created, into the UI layer, a bunch of decorators on top of those entites.  Those decorators allowed us to add some specific UI attributes related to a treeview node (like IsExpanded, for example) without adding those non-sense attributes to our business ou read-only objects in the BLL.  The decorators also allowed us to decorate an Enum to a class so that it could be view as a normal node within the treeView hierarchy and have a list of children. (so that each entity having the same enum value are located below this enum node)

We created some commands to persist move and rename action in the database. Those command actions occurs only on the server side and we don't want to refresh the whole grid to ensure consistancy between the server and client.  So we have to add logic to the client to correctly represent the server changes if no error occurs.

Now we are working on the business / validation rules.  One thing that we loved about the mvvm ideas that comes up with csla is the fact that those rules can be interpreted directly on the client when you edit a business entity.  We can then provide the user with an appropriate feedback right before he clicks the save button.  Now, for the treeview, like we use ReadOnly entities, we are not able to translate those rules.

A concrete example of a rule could be : You should not be able to move an entity that has a certain enum value (so under this enum value node) if you are not a member of a whatever LDAP group. 

Yes the move will fail on server side, but I would definitely like to provide immediate feedback to the user before he drops the entity (and trigger the move command). 

As you see, we added a lot of complexity to be able to work with readonly entites in a treeview, and it's not over.  So I would like to take a step back, even if I really don't wish to reimplement everything and discuss with the community about a better solution.

Did you guys ever went through such a situation?  Is there a way to have a cleaner solution?  Did I messed everything up?  Am I too pure about it or should I care less about having duplicated rule logic (in business entity and on the mvvm side) to provide immediate feedback to the user?

Thanks in advance!

 

 

Copyright (c) Marimer LLC