Hi,
Client has version 1.1.4 installed within their application, 170 screens in total.
They now want to move to the web, ASP.NET and are looking at a revamp.
I am presuming that there will be a good bit of work on moving to the latest CSLA?
As a very rough outline, what can I expect.
Thanks
You're basically looking at a re-write. Between the new property declarations, business rules as objects, and the switch to generics/lambdas/etc., you're not likely to save much of the current codebase. The current version of CSLA looks almost nothing like 1.1.
If you're looking to move towards the most-recent codebase, you're going to want to get the latest e-books from this site's store (if you don't have them already). They will give you a good grounding in how to use the current version of the framework. I wouldn't get any of the paper books (even the 2008 one) - there are parts that are still relevant, but IMHO not much anymore.
HTH
- Scott
Thanks Scott,
Thats a bit of a game changer. I didn't write the original application, just took it over to maintain for the client and make minor changes.
I have very very CSLA experience which makes it even more difficult and I haven't used it in similar project, just straight .NET framework.
Without asking "how long is a piece of string", if I was to convince the customer to keep CSLA and also for my own benefit, why would I bother using CSLA now if all it encapsulates is now redundant.
I know the customer has all the business rules in the CSLA but outside of that is there any point?
Apologises now if its a very vague statement to make.
Appreciate your feedback.
Thanks
Aidan
That's an entirely different question, and not really one I'm qualified to answer for you. But I'm not sure anyone is.
I will admit that in a "straight" ASP.NET environment, you lose some of CSLA's functionality, since you're not dealing with a very interactive UI technology. However, there is still benefit - integration with much of the ASP.NET infrastructure (data-binding, errors, etc.), and the overall benefits of building an object-based solution. There are also some helper controls that make using CSLA easier within the various UI environments, web included.
Regardless, I certainly wouldn't call CSLA's functionality "redundant". It provides a very robust framework for building business apps in a variety of UI technologies. In fact, this is where CSLA would really benefit you. CSLA does very well at supporting multiple front ends using basically the same codebase. So if you ever think you're going to support multiple front ends (and that can include creating a service interface), CSLA can really help you.
Ultimately, you have to decide whether the benefits of CSLA are enough for you to continue to use it. Since you don't have a ton of knowledge in the framework (perhaps none?), the first question you need to answer is whether you can/want to spend the time and money necessary to get the information to learn the framework. CSLA is not something you can learn via trial-and-error - to really understand what's going on, you need to get the e-books. These forums will help you quite a bit, but not enough to effectively use it.
- Scott
Lads,
Thanks very much for your time and detailed answers. I am now seriously doubting using CSLA if it requires me to learn it from scratch and then rewrite what is there.
I am sure there are many benefits of using CSLA but with a good code generator I will have my BLL, DAL and stored procedures.
The rules I think will be the pain to extract and to create methods to handle those.
The current system handles the data access and the business rules.
Thanks again for all the replies.
I'm in the middle of doing almost exactly this. I didn't *need* to modify the db though we did for other reasons.
As far as the business object library code (csla stuff) it is a complete re-write.
However, our app was so large with so much to port and much of it very similar that it was worth whipping up a utility to convert the repetitive tasks.
My advice is to fully learn the new csla, pick a sample business object of every unique type in your source project, port one of each manually, test and retest until happy then look at the source original code and the destination new code of each type and see what you can automate to generate one from the other.
Even if you only devote a small amount of time to it and cherry pick the 10% most time consuming things to port it's very worthwhile.
We made a little utility that you can paste in old code, select what kind of transform you need to do and it will generate the new code from it.
Saves time and ensures uniformity in the code (the most important thing of all in a big csla project)
(edit)
I should mention it's not a utility anyone else can use, we highly customized our csla originally and we use encapsulated invoke and embedded sql, no stored procedures because we support multiple db backends so it wouldn't be useful to anyone else unfortunately.
Copyright (c) Marimer LLC