CSLA .NET

I've been using CSLA and like it very much.
The community here is one of the best as well which is really great.
 Please advice scenarios when to use EditableRootListBase over BusinessListBase and vice versa. I have been using only the latter and can't figure out when to use ERLB.

~ Valentin.

The only use for ERLB is in a rich application (WinForms or WPF) where you want each row to save itself to the database as the user leaves the row, because each row can be modified independant of every other row (that is, each row is a Root object).

ajj3085:

The only use for ERLB is in a rich application (WinForms or WPF) where you want each row to save itself to the database as the user leaves the row, because each row can be modified independant of every other row (that is, each row is a Root object).

Thanks for quick response.
I think I get the idea. I'm currently working on a form (WinForms app) where I have two panes (upper is master, lower is detail, standard approach). I'm using BLBs for both panes, because I want everything to be saved upon form closing in one transaction. Is this ok to NOT use ERLB in upper (master) pane here?

Thank you
~Valentin

Excellent. Reading this post I realized that while I was using BusinesBaseList what I really need is EditableRootListBase since this is exactly what I am doing.

So, I tried to switch to EditableRootListBase and found two things. One is good and another is not so good.

1. Good thing. In my approach I had to call ISavable.Save manually, and not it's called automatically when ApplyEdit is called

2. Bad thing. We are working with local database, and our ApplicationContext.AutoCloneOnUpdate method property is set to fase, so no cloning. Now, I cannot avoid that cloning since that what EditableRootListBase does.

So, the question is why would I need to clone with local database? Can I avoid it somehow?

ajj3085:

The only use for ERLB is in a rich application (WinForms or WPF) where you want each row to save itself to the database as the user leaves the row, because each row can be modified independant of every other row (that is, each row is a Root object).

---

Maxim Alexeyev

Well, it shouldn't really matter that your object is being cloned.  The ERLB should be handling that for you.  The reason it's probably a good idea for the clone to happen (and why it is now the defaut in 3.5) is because it will help you find right away problems that would pop up should you choose to use a remote data portal.  So, it gives you clues as to what you're doing wrong. 

Is there a reason you don't want the clone to happen?

The only reason is performance. Serializing is comparably heavy operation to be used just to know what can be wrong should I decide to switch to remote data portal. I will think about that, but now I am inclined to remove cloning from EditableRootListBase.

BTW, if I really decide to move remote data portal, the cloning will still be there, right. Which will be absolutely useless since remote data portal will serialize the object late anyway.

---

Maxim Alexeyev

Well, specfically in ERLB the reason for the clone is so the user isnt' left with an invalid object displayed in the row.  I should have mentioned that before.  Imagine what happens if the save fails half way though; you no longer have a valid object for the user to edit.  The clone at least gives you the object in the state before the save was attempted.

If you move to remoting, the clone occurs because the instance is serialized and sent over the wire.  It's not cloned and then serialized; that would be useless, because when the call returns you are going to get a new object, no way around it.

So the cloning done in local mode is there so that the objects behave consistently no matter what data portal is used.

OK, I see the point. Thanks for reply.

---

Maxim Alexeyev