I am in the middle of a fairly rushed project (what else is new) and I am looking for some answers when it comes to upgrading. I haven't read one bit of literature yet on any version past 1.x of CSLA, but I don't want to make any decisions now that make it hard to upgrade later.
In December 2005 I built CSLA business objects that were designed for an existing web eCommerce application (http://www.shuttercontractor.com/) and put them into a Windows application for use with phone orders. Now I need to rip out the speghetti code in the web application and replace it with the CSLA classes that were designed for it. I will also need to create some additional CSLA classes to support adding and updating product information (I have been using scripts until now).
Unfortunately, at the time I made the application CSLA 2.0 was in development but .NET 2.0 was released already. I couldn't wait for the release of CSLA 2.0, but I didn't want to use .NET 1.1 for the project so I upgraded to CSLA 1.51 (the newest at the time) and upgraded it to .NET 2.0. I am also using ActiveObjects which is apparently no longer supported.
The main issue I am struggling with is around the security namespace of CSLA. Is there anything different about how it is designed since Microsoft introduced the concept of membership? I have a seperate Security database and I am also struggling with the notion of making it part of my website database. The Security database was designed with multiple applications in mind, however the website has a customer profile table that is dependent on the user information and having references to an outside database doesn't seem natural. I will be using roles extensively in future versions of the web application. I also will be moving this web application to a shared hosting provider at some point which is why I am considering merging the databases. If someone has upgraded an existing web application with a user account signin (with extra profile info other than username and password), I would appreciate any advice on how to make it seamless.
In addition, how steep is the learning curve to upgrade to CSLA 3.5? I have roughly 3 weeks to finish this rush project, but upgrading is something that I definitely do want to do eventually. Is ActiveObjects part of the framework now?
I am still using .NET 2.0 - what is the highest version of CSLA I can upgrade to without upgrading .NET as well?
Any advice would be appreciated.
Wow. That is a tall order.
I upgraded from CSLA 1.x to the latest version of 2.x a few months ago (for my large eCommerce web app) and it took a lot longer than I would have expected and there were many side issues that arose. I had developed a set of Base classes for 2.x prior to the upgrade (they are crucial to have.) Plus I had to learn some of the new stuff like Validation Rules.
I use code generation so I thought it would be simple to re-generate the Gen level clases for each BO (I have hundreds of BOs) and then they would "just work". No such luck though. The developer level classes all had lots of overrides in them and rules which had to be re-written. My team and I worked on the conversion for over 3 weeks and during that time we could not even compile - that's how far things had gotten out of alignment. But once it was all complete, it all compiled nicely. The testing that followed up showed there were numerous issues. Different rules may have been added during code generation; structures were changed to classes and this affected existing code; sorting on more than one property became an issue. As did filtering. I tried to use just the ObjectListView to handle both sorting and filtering but it has its own set of issues. I ended up having to also use SortedBinding List and FilteredBinding list at times.Binding and unbinding to an ObjectListView required code changes in grids to add the .Object property.
We also had to figure out how to re-write existing rules in the new style. Recall that they have the opposite result of BrokenRules.Assert.
Bottom line - it was really worth the effort. The 1.x BOs were built while trying to learn CSLA, Codesmith, VB.Net, ASP.Net, etc. The 2.x templates were built after gaining 3 years of experience with the code. Many small errors or poor coding styles were corrected during the upgrade. A lot of consistency was added too. e.g Use of DataPortal_Create for new BOs instead of use of constructors.
Depending on how big your project is and how many BOs are in it and how many developers you have and how much sleep you need - I say that 3 weeks is way too short of a time frame for the upgrade. You also need to build the templates for the BO and use Base classes to inherit from so you can extend CSLA without modification.
===================================================================
I never used Active Objects. People that do use it seem to like it. Rocky has not made it part of the framework though.
===================================================================
MS membership is something that I avoided. I have a DB and in it is my user table along with roles and permissions. I simply use custom Principal and Identity classes to load up the user object when they log in. I keep track of a lot of information for each user - name, ID, preferences, roles, permissions, etc. Much of the extra stuff is patterned after the code in the book for handling roles. e.g. permissions uses the same sort of data structure and is filled similarly. I did change them to List(Of String) instead of Arraylist to avoid boxing. I would use the merged database if I were you. There is no need for a separate security DB.
I think you can upgrade to CSLA 3.0.x and set the Net20 compiler directive so that you have the latest CSLA you can have on .Net 2.0. Rocky wo't be able to use compiler directives for 3.5 though. That version will require .Net 3.5 because of the required LINQ support among other things.
The 3.5 version is not complete or even in Beta. Rocky is still working on it and making notes about it in the change log.
The upgrade from 2.x to 3.0 is relatively painless. Especially compared to the 1.x to 2.0 migration.
I have not done it yet though because I am in the middle of a major version myself. Once it is complete I plan to upgrade to 3.x. I will probably jump to 3.5 since the timing should work out for me.
Good luck.
Joe
Joe,
Thanks for the detailed response. I have dealt with you on CSLA several times in the past and I consider you an A+ source of information on CSLA.
Basically, I have already come to some conclusions about how I will approach this based on your post and some of my other findings:
1. I will hold off on upgrading to CSLA 2.0+ until later. I have recently built 6 new ASP.NET websites using CSLA 1.51 and I have already found workarounds for the lack of sorting and paging in this version of the framework. If anyone else needs help with sorting and (SEO freindly) paging in earlier versions of CSLA (using .NET 2.0), I will be happy to share the code. To see examples, the 6 websites are:
http://www.articles-about-exterior-shutters.info/
http://www.house-shutters.net/
http://www.window-shutters.us/
http://www.exterior-window-shutters.com/
http://www.vinyl-shutters.info/
http://www.articles-on-exterior-shutters.com/
2. While there are only about 35 CSLA Business Objects in this project, it still puts me at risk (timewise) by changing the business rules - another reason I am not upgrading just yet.
3. Much of the UI will need to be redesigned in terms of the checkout process and user account to accommodate the CSLA framework. There are other fixes that can go into these processes too, so I consider this a good thing.
4. Since ActiveObjects is technically part of the framework, I won't worry about it as a dependency until I am ready to upgrade - I will need to upgrade CSLA for both the Windows and Web application at the same time to ensure I only have one set of business rules to maintain and to make sure the "Active" part of the framework migrates consistently.
--------------------------------------------------------------------------------------------------
I have worked out sorting and paging, but there is still one issue that I have never found a simple answer for when it comes to working with validation rules and multiple page ASP.NET forms - and that is when the data needs to be persisted to the datastore on each page. The issue arises because CSLA doesn't allow saving until all of the rules are valid. In my Windows application I don't want the record saved in this condition, but I do in my web application - that way if the user closes their browser, their session ends, or they navigate to another part of the site, the address and credit card data they entered will be there when they come back so they don't have to start over (provided they are logged in). I plan to mask the credit card info in the future to make it more secure.
I am already aware of the new functionality built into ASP.NET 2.0 to move the logic into one physical page. This is something I am probably going to do to make things easier. This solution still doesn't fix the "save on next step" feature that I would like to keep on my site if possible.
In the past I have actually passed a page number into the validation logic. If the page number were not passed it would simply require all rules before it could save. If the page number were passed, it would only require the rules that were on that page. This tightly coupled the business logic with the interface though. I even went so far as to put a flag in to see if the user was navigating to the next step or the previous one - if they were navigating to a previous step, the data would be saved without ensuring it was in a valid state.
I am looking for a more elegant solution than this. I would like to hear some solutions that others have come up with to handle this situation, as it has no doubt come up before.
---------------------------------------------------------------------------------------------------
As for the database, I think I will take your advice on this one. There are only 2 advantages I can think of to having the external database.
1. It provides the ability to make a single login work with all of the applications in the organization.
2. Potentially an application could be built to manage all of the logins and roles in the organization.
The reality is this is a small business and I took the seperate security database model from a company with dozens of applications and databases to maintain. Neither of these 2 items are a requirement for this situation.
I have a few questions about how you laid out the structure of your application though:
1. Did you keep the profile data in your user table, or did you have some other kind of database table structure?
2. I take it you used a custom Identity class to store the profile data (you didn't specify which). Do you have a business-specific version of CSLA (an inherited framework with all of your customizations)? If not, how did you get it to read the custom Identity and Principal classes?
Currently I don't have a CSLA business framework (other than ActiveObjects). I am in pretty bad need of one though since I have added many customizations. I just need to know if this is the point I need to do this step or not so I can get some idea how much work is involved.
Thanks again,
-NightOwl888
NightOwl,
1. I have a few tables in the DB to handle roles and permissions. Off the top of my head, there is a user table with information about the user: name, email, status, many other values including module level permissions which are Boolean flags showing if the user can get into different modules. (We use those to control licensing levels.) We also have a table for defining system level roles and permissions. We define them and add them to the product. The client gets to assign the various roles and permissions to their user base. The assignment of roles and permissions occurs in other tables. I also have to support an older system of permissions (pre-.Net) which I map into the current style using internal routines. This allows the older system to stay in use until it is converted over to .Net and then the internal routines can be removed and we can load up the permissions the same we we do for all the others.
2. I do use custom Principal and Identity classes. Nothing else. I store the Principal object in Application Context and always have access to it while the user is logged in because it is in Session. The context gives you access to it as an IPrincipal or IIdentity object so you only have the ability to use the "standard" interface methods if you use it directly. But you can simply cast it to your custom class and then have access to all your custom Properties. That is all I do.
3. I do not make extensive use of CSLA Authorization - just some basic stuff. But I spotted a major drawback in the early versions of CSLA Auth which is that it is not extensible. It always calls IsInRole for you. Well, I have a few roles and hundreds of permissions and I wanted it to call HasPermission instead. This was not possible. Rocky just added it to the current version though by using a Delegate which defaults to IsInRole for backward compatibility. But now I could assign my HasPermission function to it and that would be called instead. This was a major breakthrough. And the code to add it in to older versions of CSLA is really quite small if you need something like that. You can read the code on line in Rocky's source control.
Joe
Copyright (c) Marimer LLC