CSLA .NET

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

Implementing multiple DalManagers?

rated by 0 users
Not Answered This post has 0 verified answers | 7 Replies | 0 Followers

Top 50 Contributor
168 Posts
gajit posted on Wed, Feb 22 2012 12:22 PM

I need some advice, or recommendations.

I've successfully implemented my custom authentication model, which retrieves/validates user credentials from a separate 'Security' database than the 'application data'.

My problem is, is that the implementation of ConnectionManager is done in DalManager;

Public Sub New()
        ConnectionManager = Csla.Data.ConnectionManager(Of SqlConnection).GetManager("Security")
    End Sub

so do I need to create a separate library for my Security classes and subsequently reference the DalManager in that Library?

Or is there another way whereby I can specify the connection in my bo/concrete dals?

Thanks,

Graham

 

 

All Replies

Top 10 Contributor
2,188 Posts
JonnyBee replied on Thu, Feb 23 2012 12:46 AM

I'd rather not have the connection defined like this in an instance variable. In an N-Tier application you may experience serious performannve problems if the app only has one connection available .

The ConnectionManager will return the "same" connection in "nested" contexts so I prefer to just let the data access code use the ConnectionManager and use the connection for as short as possible time period.

It is your code that introduces the limits.

 

Jonny Bekkum, Norway CslaContrib Coordinator

Top 50 Contributor
168 Posts
gajit replied on Thu, Feb 23 2012 6:52 AM

That doesn't really make things any clearer for mr Jonny.

This DalManager is the one used in the examples in the eBook series and in the sample code.If this isn't the correct implementation than how SHOULD it be implemented?

I don't understand why we go to the trouble of doing something like THIS in concrete Dal:

 Using ctx = ConnectionManager(Of SqlConnection).GetManager("Security")
            Using cm = ctx.Connection.CreateCommand()
                cm.CommandType = System.Data.CommandType.StoredProcedure
                cm.CommandText = "VerifyUser"
                cm.Parameters.AddWithValue("@ps_Username", username)
                cm.Parameters.AddWithValue("@ps_Password", password)
                cm.Parameters.AddWithValue("@pn_IsValid", 0)
                cm.Parameters("@pn_IsValid").Direction = ParameterDirection.Output

                Dim r = cm.ExecuteScalar()
                Dim newId As Boolean = cm.Parameters("@pn_IsValid").Value
                Return newId
            End Using
        End Using

When ultimately the settng is pulled from that hard coded value in the connection manager??????

Why?

Graham

 

Top 10 Contributor
2,188 Posts

Because ConnectionManager maintains a reference count and allows you to write code that does not send the connection as parameter on a number of functions - but still the the database calls are made on the SAME connection and transaction.

Think:   root.Save - save children - save grandchildren all executes on the same connection and transaction without having to send the connection object as a parameter in your code

This is handled inside ConnectionManager that "stores" the actual active connection in a slot on the current thread and maintains a reference count so that when the "top-most" using goes out of scope the connection is closed and transaction is submitted or if an error occurs the transaction is rolled back.

 

Jonny Bekkum, Norway CslaContrib Coordinator

Top 50 Contributor
168 Posts
gajit replied on Thu, Feb 23 2012 8:31 AM

Clearly i'm too !#@#!* dense for this...

The csla 2 implementation was quite clear and concise.

My dataportal methods determine the connection I want to use - why the connection manager has any need to do the same I don't get.

THIS is CSLA 2 code:

        Using cn As New SqlConnection(Database.SecurityConnection)

            Using cm As SqlCommand = cn.CreateCommand
                cm.CommandType = CommandType.StoredProcedure
                cm.CommandText = "VerifyUser"

                cm.Parameters.AddWithValue...

Simple, concise and most importantly, the CSLA books at the time documented and explained this methodology in its entirety.

My biggest obstacle in all of this is the the books, samples, etc do NOT provide that same level of understanding. I am constantly trying to interpret what is provided as a sample as opposed to what will actually work.

Many developers just want to pick this up and run with it. Be told what is the correct implementation. Not be presented with something that *might* work.

As the Custom authentication model is still supported by CSLA and as such the concept of multiple databases is supported, then why is there no CLEAR definition of how to implement this in the Samples or in the eBooks?

Graham

Top 10 Contributor
2,188 Posts

The code from CSLA 2 is still valid for CSLA 4.

But when in a parent/child structure you will always have to send the connection object to all the children - thereby making you BO's code/interface tied to that data access technology. Somewhere down the line in development CSLA object interfaces should not be that influenced by the choice of data access layer.

So the ConnectionManager, ContextManager and ObjectContextManager are helper classes to make the code look pretty much the same -  less code to edit/change in your BO's.

 

Jonny Bekkum, Norway CslaContrib Coordinator

Top 50 Contributor
168 Posts
gajit replied on Thu, Feb 23 2012 10:29 AM

And that's the thing. I'm trying to move forward and implement data layer non-specific objects, but using the structure set out in the samples and books, it's not possible to do what I require. And that is to have a connection manager that just pools the connection that is specified in the bo.

What Im saying Jonny, how is it implemented? How do I create a bo and dal implementation that has a connection manager that supports multiple specified connections? As it stands, the code that passes the "connectionname" in the business object is basically ignored - and I don't see how I can control the connection manager, so that it uses different database connection strings.

Maybe I'm wrong, maybe there ARE samples, but I dont see them.

Graham

Top 50 Contributor
168 Posts
gajit replied on Thu, Feb 23 2012 11:55 AM

FYI.

As it stands the way I've had to implement this, is to create separate objects.

DataAccess

SecurityDalFactory.vb

DataAccess.SQL

SecurityDalManager.vb

My BO's in Library.Net implement the dalManager as:

Using dalManager = ParabolaSols.DataAccess.SecurityDalFactory.GetManager()

 

 

 and obviously I now have an app.config entry that represent "SecurityDalManagerType"

I'm all "thinked out" on this. But hopefully that will endure the test of time until someone can come up with a more compact approach - if there is one.

Graham

 

Page 1 of 1 (8 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