BeginEdit/CancelEdit and all-object gragh

BeginEdit/CancelEdit and all-object gragh

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


d3vil posted on Wednesday, April 16, 2008

hey,
I'm using CSLA (3.X) in a non-traditional way, beside the fact that I use DTO's and NHibernate, my relations between objects (in the BO level) are objects and not Id's fields (e.g. Project has a user object , not Project has a UserId field).

the problem in BeginEdit/CancelChanges is that I have different copyState behavior for different relations:
A relation of a simple foreign key as lookup (like project and user, or Post and Tag).
A relation of Parent-Child (like Test and result),

The difference in behaviors should be something like this:

The problem I talked about was deserialize a NHibernate object. because deserialize creates a new instance then the current NH-Session won't be associate with it, and that is just a recipe for other problems (I don't really want to re-associate objects each time i hit cancel edit).

currently I refactored the CopyState/UndoChanges/AcceptChanges so each logical question can be overridden and each logical Copy/Undo action can be overridden also,
in my domain's BO-Base class I decide what is the relation according to an attribute on the field. When I need to cancel changes on a looked-up object, I just re-load it from the DB (in copyState I save its Id).
Also I don't have the option to switch to CSLA 3.5 (.Net 3.5 etc..., or want to, personally i just don't like the heavy use of refraction every where) of that will be to much of  breaking changes.
I don't like this solution very much, and I wonder if anyone else stumbled upon this problem, and how you think is the best way to solve it?

10x,
d3vil.

RockfordLhotka replied on Wednesday, April 16, 2008

Doesn't the NotUndoable attribute get you what you want? Mark the fields you don't want serialized as NotUndoable and they will be ignored by UndoableBase.

d3vil:
hey,
Also I don't have the option to switch to CSLA 3.5 (.Net 3.5 etc..., or want to, personally i just don't like the heavy use of refraction every where) of that will be to much of  breaking changes.
I don't like this solution very much, and I wonder if anyone else stumbled upon this problem, and how you think is the best way to solve it?

CSLA 3.5 doesn't require any increase in the use of reflection. The primary place reflection is used more than in the past is if you use the new data portal features that simplify child object persistence - and that is entirely optional (so you can choose between saving lots of code vs getting optimal performance). And even there, the reflection is minimal because the data portal in 3.5 now uses dynamic method invocation, and thus is substantially faster than 3.0 in many cases.

Arguably the object-level authorization scheme increases the use of reflection by making one reflection call per type per instance of your application. So if you have 100 business types, you might incur 100 reflection calls - which is no big deal at all.

You must remember that any use of data binding has always involved tons of reflection. All Microsoft's data binding infrastructures (Windows, Web, WPF) are very reflection-intensive. CSLA's use of reflection is very, very minor compared to Microsoft's use of the technology Smile [:)]

d3vil replied on Thursday, April 17, 2008

hi Rocky,

One thing at a time.
First, the NotUndoable:
No.. it doesn't help me because I don't want the field to be saved...
think of this both Post and Tag are BusinessBase<T>:
Post p = Post.get(id);
// p.Tag == HelloWorld
p.BeginEdit();
p.Text = "blab alba bla";
p.Tag = Tag.Get("C#_Tag");
p.CancelEdit();
///more stufff

In that case I would expect that Tag will reference an HelloWorld tag and not C# tag...
in a prefect world I would serialize Tag as an whole and in CancelChanges deserialize it back to p.Tag, but in NH that isn't a possibility. - BTW it would be nice to add to the IUndoable methods points to expend or replace some of the logic. (as I said, I'm currently modified it myself in CSLA whice is a thing I don't like to do..)

I hope you understand my problem now.

Now about the reflection stuff.
I used to allow my BO programmers to use CanReadProperty(), CanWriteProperty() and PropertyHasChanged() - with no parameters...
those method use callstack and reflection to get the properties names (which can be very nice when a big change is done to the data model).
I have several use-cases when the user edit/create hundreds or thousands of object, I took a .Net profiler and you won't believe how much time is "wasted" on those methods (and not only with  hundreds object, even much less (tens...) - I'm sorry that I don't have any number to give you, but that was long ago and on a performance sprint to ship the version.

as for data_portal, I looked briefly on the thread that discussed the dynamics methods and stuff and didn't yet had the chance to fully read and review the new design (will do as soon as I have the time) - I'm seriously consider to make my own CSLA hybrid with taking the new data-portal design and implement it in my current modified CSLA3.X without the parent-child code.

I always wondered why you didn't use interfaces over there(data-portal) instead of reflecting on the object several times (which looks very redundant....)

anyway now when using NH the use of data portal is very very different because NH saves all the object graph in one save call.

and last but not list, Binding.
yes.. I know MS binding is a bunch of reflection on top of more reflection and I hate that, and when I can I prefer not to use it.


anyway this thread is just for the sake of discussion because I don't really belive that my original problem has a better soltion then the one I implemented, but if there is.... I will gladly apply it to my code.

d3vil.

Copyright (c) Marimer LLC