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
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.
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
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.
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
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.
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
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
Copyright (c) Marimer LLC