CSLA .NET

I've looked at the Deep Data example and I'm not quite seeing what I want to know. It is a very basic example that shows how do Parent, Child and Grandchild fetch and also use several different Data Access Layers which is great. I think what I'm looking for is a model where the actual code to handle the create, insert, update, and delete of the objects in my library are encapsulated in the DAL. That way I don't need to have this code in the business object.

What I'm trying to do is write a client server application that can access the data source while in the office through a Direct connection to the SQL server and while out of the office they will access data over the web. I want both the DAL.SQL and DAL.WEB to have the same methods. I think for some reason and I don't know why, that the DAL.SQL and DAL.WEB need to reference the Object Library so I'm a little confused on the dependencies and how this is all organized.

Does anyone have an example that I can use or  maybe they have questions about what I'm trying to accomplish...

Thanks,

Chris

Chris,

If you use remoting or a web services on a web server you may not even need to care what access mode the system should use or when to switch between them. You can then use the standard DataPortal methods with the appropriate code inside them.

Chris,

I am in the same boat. I am working through converting an existing app to use a data access layer although I am doing it to make the app more unit test friendly. This is a list of things that I've run up against so far, maybe some of them will help you. Keep in mind that I am in the process of doing this and am learning something new about it every day (hour?).

1. I originally wanted to go directly to a DTO type layer but decided that that was a little too much to bite off in one pass. DTO feels like it adds a fourth (fifth? App->BLL->DTO->DAL->DB, call it 4.5) layer. So I am starting with an equivalent to DeepData.DAL.Direct.
2. I looked at code generation but decided that for now I need to hand write the layer to really understand what I'm doing.
3. I too struggled with how insert, update and delete fit into the DAL space. Rocky was nice enough to give me a hint in an email that got me pointed in the right direct. It finally dawned on my that the DAL is like .NET stored procedures. I had to start thinking about it like it was a new type of database that I was programming against.
4. Updating or inserting children was another problem. I read about ApplicationContext.LocalContext when CSLA 3.0 came out but did not think that I had a need for it so I never used it. Now it makes sense because it's the best way to pass a transaction from a parent to a child.
5. Because it seems like the parent should decide if a transaction is complete I'm thinking that the parent DAL needs a commit function or sub.
6. I started out wanting to get DataPortal_Fetch, DataPortal_Insert etc. in the DAL. Those routines have to stay in the business layer but all of the code related to creating the connection, sql command and executing it are replaced by calls to the DAL.
7. I had problems understanding how to return things like identity values or field changes from the DAL when I really didn't need the entire object back. Force of habit had me thinking that returning a SafeDataReader was only used for returning an object, once I got by that I realized that I can use it to return anything although I will have to change my stored procedures and replace the I/O parameters with select statements to return what I want.
8. Dependencies. I looked at the project dependencies in DeepData. The one that I missed that caused problems is that the application needs to depend on DeepData.DAL.Direct etc. Otherwise the DLLs aren't available to load because there is no dependency between DeepData.DAL and DeepData.DAL.Direct etc.

Hope this helps.

Dave Erwin

Hi Dave,

I'm sure several of us would ever be so grateful for some code examples.

<whine>
Things I'm struggling with, the Criteria Classes. Does this move the the DAL  assembly? Seems like it but I'm not sure. Rocky is, well to be blunt too smart for me! His DeepData example is too complex, I'm sure he feels its a simple example, but not for me. It's difficult for me to separet the code that exists ONLY to accomadate the vairous data access channels versus just the code I need to implement. This leads to my uncertainty re the DAL, DAL.Direct and DAL.DTO assemblies. Do I really need them all? Plus I suck at reading VB. I've converted the sample to C#, but it's not perfect, so it does not run.
</whine>

Anyway, your previous post was has been useful already. I'm now using the LocalContext to access the transaction and connection.

Harry,

 

I pulled one of the simpler classes out of my project, hopefully this will help. Again, I'm just getting started with this myself but this is working (at least in testing). Unfortunately it's in VB since that's what I work in. I can read C# but wouldn't even attempt to post an example in it for fear of being laughed out of the forum. Then again this example may do that anyway... The attachment is just a zipped PDF file. I didn't have time to put together a whole solution.

 

The short answer to the criteria question is "no". I struggled with the same thing but as you'll see what really gets moved to the DAL is the DataPortal_XXX code starting with the connection and ending with the command execution.

 

In my implementation there is currently a DAL project (DataAccess) and a DAL.Direct project (DataAccess.Direct). When I start to implement DTOs there will be a DAL.DTO project. Changing the config file will be all that is required to make a class use DTO instead of Direct.

 

HTH,

 

Dave Erwin

Hi Dave,

Appreciate your effort immensly. IMHO you went above and beyond.
Thank you! and the PDF format is pretty cool!!

So I'm not too shy, here's my attempt at getting laughed at.

Here is what I have so far. I've tried to re-create deepdata with my own BOs(well one) and only ONE data-access channel, Direct.
So, so far here are the projects I have in my solution, in the order they appear,
DAL
DAL.Direct
DataLibrary (business objects)
UI

I got Fetch to work, but hey I had an example to work from!!!
Now I have an insert example to work from too! Thank you.

I think our DALs are pretty close, although I've deviated. I have to go and relook at the point of the DataFactory. For now I just do this.
it's in C#, I wouldn't attempt VB :-)
Oh, and Configuration is a BO.
Type dalType = Type.GetType("DAL.Direct.Configuration,DAL.Direct");
return (Configuration)(Activator.CreateInstance(dalType));

Um, since it's not configurable(my version), I'm not sure what the point of this is, except it makes duplicateing deepdata easier for me.

Anyway....Criteria is staying put and I'm passing an int or two as required.

I've been working on the update and your example was helpful to me. Been trying to pass this/me and all kinds of funky stuff to get at the data to pass to the update parameters, but getting nowhere. I see that you pass parameters, which is a bit depressing for me. My test BO (which is a partial real BO) has 19 fields, some have more :-(   soooo what I've decided on, for better or worse, is yet another project in my solution, DataStructures (a bunch of strucs), referenced by the DataLibrary and DAL.Direct and used to pass data back and forth, well mostly From DataLibrary to DAL.Direct, but I don't see why not in the other direction as well.

My (attempted) point of the DataStructures is to ease maintenance of parameters, make things easier to read and manage. Our Data Model is still in flux (weep), so I find myself going back and regenearating the BO, stored procs, etc. moer often than I wish.

This is what my solution looks like now.
DAL
DAL.Direct
DataLibrary (business objects)
DataStructures <--- new
UI

Now back to checking out your sample....  :-) I read VB slooooow.

Your exmaple is cool, thanks again
HS