Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

CSLA.NET

Download

Right click “Save as…”

In this episode, Rocky Lhotka joins us to talk about CSLA.NET. CSLA is a software development framework that helps you build a powerful, maintainable business logic layer for Windows, Web, service-oriented, and workflow applications. Its primary goal is to help you implement, manage, and reuse business logic. Rocky introduces CSLA.NET and then shows us how the upcoming version supports async programming and Windows 8 apps.

Tag:

Follow the Discussion

  • EttyEtty Think big, be big!

    Hi Mr. Green. I really like your swag. I am a fan of yours. I have a question.
    There are frameworks being built to bridge the 'impedance mismatch' gap created by trying to map the database to OOPs. Could you please tell me how this gap is being minimized by some of the frameworks out there?

     

  • KavehKaveh

    CSLA is awesome (and so is its creator of course!).

    While Rocky was presenting the WPF sample, he set the DataContext of the view to a CSLA object which is supposedly a Model object and not a ViewModel object. Now I understand that this was for the purposes of the presentation and brevity but since these objects already have the change notification, validation etc. built into them I was wondering what would be the correct strategy when wrapping these objects in ViewModels. Exposing these models as public properties would break the layering concept and not exposing them would require reimplementing all the public properties of the wrapped Model object, change notification etc. And by the way, what is used in theses objects for binding OK and Cancel buttons? Command objects?! Wouldn't that (again) break the layering? What if one wants to wrap the cancel object with a confirmation first? Out of top my head wouldn't it be nice to have a maybe dynamic object creator mechanism that wraps CSLA objects and re-exposes their properties with the option of adding extra responsibilities?

    I'm wondering if one can leverage the infrastructure already available in the CSLA framework for creating object graphs for a View-Model-pattern-backed framework since a lot of concepts are similar here ...

    I really liked what Rocky said about the Javascript in WinRT ... totally with that!

  • I've been a Rocky & CSLA fan ever since I read his book on VB6 Business Objects. Cool While my current projects don't lend themselves to that framework (different architectural paradigms), I've learned a lot from CSLA and my use of it in the past.  (Though I never did like its DataPortal implementation of a facade over the data access layer, it always seemed like a hack to not just map CRUD operations directly to an interface... And CSLA's properties could be much, much nicer with metaprogramming facilities available like in C++...)

    Where can I get the cool Magenic wallpaper with the Technical Relevance chart?  Looks like a great orientation tool.

  • @Kaveh: The idea of domain driven business objects predates the current MVVM concept.

    The idea behind a viewmodel is two-fold. First, the assumption is that the model object is in the wrong shape, so the viewmodel needs to expose the properties needed by the view because the model is wrong. Second, the assumption is that there'll be actions specific to the presentation layer that won't (and shouldn't) be implemented by the model.

    If you do a good job designing your domain business objects they _will_ be in the right shape. And if you use CSLA then they'll also be fully bindable. So you really don't want or need a viewmodel to reshape the model, because the model is right to start with. Because of this my viewmodels tend to just have a Model property that directly exposes the domain object to the UI.

    I do still have a viewmodel though, because the second reason (presentation layer actions) is _extremely_ valid, and I absolutely recommend using viewmodel objects to address this requirement.

    CSLA includes a ViewModelBase class (in Csla.Xaml) that helps you create a viewmodel that exposes a Model property and provides protected members to make it easy to implement some common presentation layer actions.

    I discuss this at some length in the 'Using CSLA 4: WPF and Silverlight' book. This is also a common topic on the forums (http://forums.lhotka.net) and on my blog (http://www.lhotka.net/weblog).

  • @Lars Kemmann: I might agree about the data portal if it were only a facade, but that's not the case.

    The primary purpose of the data portal is to abstract the entire concept of an "application server", thereby providing location transparency. When you call the data portal your code doesn't know if the app is deployed in a 1-, 2-, 3-, or 4-tier environment, and it doesn't need to know or care.

    Additionally, the data portal automatically manages a number of common requirements such as impersonation of custom principal/identities from the client, flow of client culture onto the server thread, abstraction of network technologies (Remoting, asmx, WCF, Web API, raw TCP, etc).

    It is true that the data portal could have been interface-based. I conciously chose not to go that route because I wanted to support method overloading, thus allowing you to have different read (fetch) method overloads to support different application scenarios.

    That said, the current CSLA 4.3 data portal does provide a number of important interfaces necessary for mocking and unit testing scenarios, including at the data portal level. If your primary concern was around mocking and testing you might find that the concern no longer applies in current versions of the framework.

  • @RockfordLhotka: Thanks for responding!  I wasn't aware of the impersonation/culture flow - it's nice to have that, especially since the average developer (me) wouldn't have thought of that (getting to your point about the value of frameworks).  Although, again, I could make an argument for using an interface with an optional abstract base class to help out those who are providing CSLA "adapters" to various persistence locations/schemes...  Anyways, I think the most recent version of CSLA that I used was around 3.6-ish, so I'm definitely behind the times somewhat.

    So... about that wallpaper...? Smiley

  • Nicely done.  

    What are your thoughts on CLSA.NET versus the  the new LightSwitch product for a large LOB app ? (I have no experience in either) -- in particular, whether LightSwitch provides the same level of seperation of concerns that CSLA.NET does.  What are the driving forces to chose one over the other?  There's a thread on this topic at http://forums.lhotka.net/forums/t/9411.aspx but it's two years old now.

     Thanks.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.