Not sure if this is the right place to post this but here it goes anyway! I managed to get the new VS2008 beta up and running on my machine. This was very exciting sicne the previous CPT was not working so I could not really get to play with all the new CSLA features :-(
In any case, I managed to compile and start playing with the CSLA 3.0 and the new PT project and am getting quite excited. But one thing I noticed is that the main topics that will be covered in the book are WPF and WCF support. Now although that's cool, I personally am looking forward to play with WF. So Rocky, if you get to read this, I would just like to make a request that WF is not too sidetracked :-) (I saw the WF project but it looks quite basic for someone like me...)
The reallity is that even though all WPF, WCF and WF can be learned by other tutorials, books etc, I find all the CSLA books to be much more than just a source to learn about CSLA and designing frameworks. To me they are also a very importan guide to new features of the .net frameworks. I would not know that much about generics if it wasn't for CSLA...
triplea:
But one thing I noticed is that the main topics that will be covered in the book are WPF and WCF support. Now although that's cool, I personally am looking forward to play with WF. So Rocky, if you get to read this, I would just like to make a request that WF is not too sidetracked :-) (I saw the WF project but it looks quite basic for someone like me...)
I appreciate your kind words and input!
The thing about WF is that it is very much like web services or WCF services from a CSLA perspective... That is to say that there's not a lot of interaction between the two, and so CSLA doesn't provide a vehicle for going deep into those technologies.
An app built with CSLA can call a service or start a workflow. And I'll discuss this aspect of using WF in the ebook. But really this is kind of boring stuff, because there isn't much complexity with launching a workflow from a DataPortal_Execute() method (though there are some interesting subtle issues I'll discuss).
And a service or activity can be built using objects "on the inside". Clearly the external interface (presentation) is defined by the technology, but your service/activity then becomes the "UI" that invokes the object(s) to do the work. But again, this isn't particularly complex. The interesting thing here is more at a design level, where it is important to think about a service/activity as being an individual use case - and I'm discussing this to some degree in the WF chapter of the ebook.
There are issues with making a CSLA object (or any custom type) a dependency property on an activity or workflow, and I'll discuss that. And there are some differences between a basic code activity and an activity from a separate assembly, and I'll discuss that as well.
So there is a chapter just on WF, but to be honest it will be one of the shortest chapters. The intersection points between CSLA and WF are somewhat limited, and those are the points I'll be covering.
If you have specific areas, beyond those above, where you think CSLA and WF do intersect please let me know (asap!) and I'll consider discussing them as well.
Thanks for the reply Rocky! I understand what you mean by saying that the interaction between CSLA and WF is somewhat limited. What got me really interested in WF was something you wrote in your blog once (or was it the forum?). You stated that if combined properly, WF and CSLA objects can give the best of Procedural Programming and OO. I believe that's what you meant you will be covering when you said:
"The interesting thing here is more at a design level, where it is important to think about a service/activity as being an individual use case - and I'm discussing this to some degree in the WF chapter of the ebook."
Admittedly I do struggle designing objects that are the "workflow controllers" if you like and quite independent "parent" objects that act like they are in a sequential workflow and are managed by these controller objects. If not then I would love to hear more about your statement above!
In any case I trust the chapter will be most informative. I will (eagerly) wait for the ebook to be released and then there is always the forum to expand on it.
Admittedly I do struggle designing objects that are the "workflow controllers" if you like and quite independent "parent" objects that act like they are in a sequential workflow and are managed by these controller objects.
Hmm, I don't think I'm framing my discussion in that light.
I see the idea of objects launching workflows as one thing. This is not unlike objects invoking a service: the object (typically a command object) needs to perform some command or operation, and that operation is implemented (in whole or part) as a workflow. The object has no idea how the operation is implemented, just that by running the workflow it gets the desired result.
Then implementing activities using objects is another thing. At this level the activity is being executed by the workflow where appropriate. Since each activity is (or should be) a black box, the workflow doesn't know or care how the activity is implemented, and inside the activity you merely call business objects to do the work.
Workflow becomes a layered set of abstractions. The caller of the workflow sees a black box that does some operation. The workflow sees a set of activities, each of which is a black box, that it executes in order, controlling the flow according to the behaviors of each other activity (such as an IfElseActivity or state transition or whatever).
So there are no "controllers" as such. Just procedural invocations.
It is like an "object sandwich". At the top is your OO business layer. In the middle is the procedural workflow, and at the bottom (inside the activities) is your OO business layer (perhaps a different one from the first, or maybe the same).
Copyright (c) Marimer LLC