Migration to CSLA 2.x

Migration to CSLA 2.x

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

JonM posted on Thursday, November 16, 2006

Hey everyone,

I've got a large winforms application that I just finished in CSLA 1.5x.  The application is actually built-on .NET 2.0 but uses the CSLA 1.5x framewrok because the CSLA 2.0 did not come out until we were like 80% done with the project.  Now there are 2 big migration problems I see.

  1. We implemented our validation using the dead CheckRules() pattern.  I saw a lot of complaining about it in the forums, but we got it to work just fine.
  2. We have rolled our own security model that is nothing like the CSLA 2.x security setup.

Here are my question

  1. Can I just ignore the new CSLA 2.x security model and use my own?
  2. Is there anything I can do to convert validation rules while I'm still using the CSLA 1.5x framework so the transition to 2.0 won't be so bad?

JonM replied on Tuesday, November 21, 2006

No takers on this one?  I know migration isn't going to be easy but any advice from the CSLA.net gurus would be great.

ajj3085 replied on Tuesday, November 21, 2006

Search on this forum, others have posted their upgrade experiences here. 

Mainly you'll need to focus on validation rules / auth rules, and how DP_C is called.  I can't quite recall anything else at the moment, but Rocky's change log gives a pretty good indication on the major areas that could cause pain.

HTH
Andy

RockfordLhotka replied on Tuesday, November 21, 2006

JonM:
  1. Can I just ignore the new CSLA 2.x security model and use my own?
  2. Is there anything I can do to convert validation rules while I'm still using the CSLA 1.5x framework so the transition to 2.0 won't be so bad?


1. Yes, you can simply ignore the authorization support in CSLA if you'd like. Alternately, you can override CanReadProperty() and CanWriteProperty() and replace those methods with your own logic - thus partially integrating with the existing infrastructure. That might be best if you can make it work, as you'll be able to take advantage of some new features in this area over time (like IAuthorizeReadWrite).

2. No, this one is difficult. If you used the BrokenRules.Assert() approach in 1.x there's nothing to be done but convert the rules to rule methods. However, the process tends to be rather mechanical. BrokenRules.Assert() needs the property name, a human-readable description and a conditional - which is exactly what you need to implement a rule method.

However, if you are using the CheckRules() concept in 1.3 or higher, that is pretty close to the 2.x model, and so conversion shouldn't be too difficult.

JonM replied on Sunday, November 26, 2006

We'll I've converted a few of my classes to CSLA 2.1 and created a checklist of what has to be changed.  Conversion to the new business rules has not been that difficult.  However, there are just a lot of other minor changes.  In general, I'm in favor of all of the changes, even the dataportal changes that break up the Insert and Update code blocks.  I'm starting to think that the easiest and cleanest thing to do will be to just dump my 1.5x business objects and rebuilt them from scratch using the class templates that are included with CSLA framework.  I should be able to keep my database schema, my sql stored procedures, and my .NET 2.0 winforms client.  I'm thinking I should just swap out my middle tier with a rebuilt CSLA .NET 2.0 dataportal.  Do you forsee any nasty issues with databinding differences to 1.5x and 2.x objects?  Note, my current 1.5x project is already using a .net 2.0 winforms client and databinding.

Copyright (c) Marimer LLC