CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Sharing a transaction via CriteriaBase?

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 3 Replies | 2 Followers

    Top 50 Contributor
    187 Posts
    JCardina posted on Tue, Nov 27 2012 6:44 PM

    I have a read only object which fetches inventory values.  It needs to optionally accept a transaction object because it's sometimes used to simply display values to the user but at other times it's used by an inventory adjustment object which needs to check current inventory before making changes inside an isolated transaction.

    I'm experimenting with passing the transaction as part of a complex criteria (I also need two Guid's so there are three parameters).

    When I try to specify the managed propery for the transaction like this inside my CriteriaBase class I get a complaint from visual studio:

    public static readonly PropertyInfo<IDbTransaction> TransactionProperty = RegisterProperty<IDbTransaction>(c => c.TransactionProperty);

    "Cannot convert lambda expression to type 'Csla.PropertyInfo<System.Data.IDbTransaction>' because it is not a delegate type"

    Is there any reason why I need to use the managed properties in my CriteriaBase derived class?  I'm a little confused as to why I need them to simply pass data from one object to another.

    Is there a better way to share transactions between objects than this?  

    Answered (Verified) Verified Answer

    Top 10 Contributor
    9,475 Posts
    Verified by JCardina

    This is the reason for the various transaction/connection/context types in the Csla.Data namespace.

    I discuss their use in the 'Using CSLA 4' ebook, and they are specifically designed to "flow" connections/transactions between your DAL components without having to deal with the complexity you are currently facing.

    Rocky

    All Replies

    Top 10 Contributor
    9,475 Posts
    Verified by JCardina

    This is the reason for the various transaction/connection/context types in the Csla.Data namespace.

    I discuss their use in the 'Using CSLA 4' ebook, and they are specifically designed to "flow" connections/transactions between your DAL components without having to deal with the complexity you are currently facing.

    Rocky

    Top 50 Contributor
    187 Posts
    JCardina replied on Wed, Nov 28 2012 11:10 AM

    Ahhh!  I've read all the ebooks but I missed that somehow the first time around, I'll dig through it, thanks Rocky!

    [I don't know how I missed that before, was it added in a later revision from the first book release?]

    Top 50 Contributor
    187 Posts

    Just an FYI for any future readers of this issue: If you can't use the built in transaction types in the csla namespace as I can't it *is* possible to use the far simpler method of setting a shared transaction property in the enlisted other object.  You just need to set it's backing property to nonserializable and it works fine.

    So just create a property in the secondary object that will be enrolled in the transaction that holds the shared transaction, give it a backing field set to nonserializable and Bob's your lobster.

    Page 1 of 1 (4 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems