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