Deep Data pattern - Inserts/Updates

juddaman posted on Sunday, January 13, 2008

Hi

I want to implement my data access code in a seperate assembly. I've copied the DeepData example for Fetches but am a little unsure how to do the Inserts/Updates. This is what I have done (using the terms in DeepData):

In DeepData.DAL, DeepData.DAL.Direct and DeepData.DAL.DTO I've added a OrderDAL class.

They have a method, InsertOrder(object data);

In the DAL.Direct InsertOrder method I check data is of type Order.
In the DAL.DTO InsertOrder method I check data is of type OrderDAL.

In each case I throw an ArgumentException if data is not of the correct type.

In DeepData.DAL.DataFactory I've added a method InsertOrder(object data). This creates the correct type of OrderDAL and calls the InsertOrder method on it passing it the argument.

Is this how others have dealt with Inserts?

Thanks George

juddaman replied on Monday, January 14, 2008

Okay. Let me ask this question in another way.

When porting DeepData example to C# how should one handle the change from dynamic typing?

Is it the case of adding seperate FetchDto() methods.. i,e, FetchMyDto(), FetchLinqDto() etc? Then alter FetchDto() so it calls the correct FetchxxxDto depending on the type returned.

Or maybe use an adaptor to convert all returned to MyDto types. Then just have a FetchDto()?

Any help is much appreciated.

Thanks, George

RockfordLhotka replied on Monday, January 14, 2008

I only used VB's dynamic language features in the sample because the sample transparently switches between LINQ, web services or straight DTOs. I didn't want messy code to deal with three types with the same shape but different types.

In a "normal" app you'd almost certainly just pick one of those techniques. The result is that you'd have one set of types and so you can just use strong-typing directly against those types. For example, the business assembly can reference the LINQ DAL assembly and just use the LINQ DTO types.

For update/insert/delete operations, I recommend having the DAL implement methods that accept strongly typed parameters for those operations. This is what the DAAB does, and what you'll get with LINQ to SQL automatically. Many other DAL tools work that same way.

You can get an idea of what I'm talking about by looking at the Data Access region of the new Resources class

http://www.lhotka.net/cslacvs/viewvc.cgi/trunk/ProjectTrackervb/ProjectTracker.Library/Resource.vb

I know it is VB, sorry, I'm still porting the new property declaration code to C# before I can convert ProjectTracker... But you can see how the LINQ DTOs are used in DP_Fetch/Insert/Update/Delete. All that comes from a totally separate project (ProjectTracker.DalLinq) that is only deployed on the app server.

juddaman replied on Tuesday, January 15, 2008

Hi Rocky

Many thanks for your reply. Yes in a normal app I guess only one method would be needed. I was just trying to see if there was an elegent way of implementing the dynamic typing in C#. Also for speed comparisions etc.

I've had a look through the new Resources class and the PTrackerDataContext class. Is the PTrackerDataContext generated code? Would you always recommend passing each data element as a parameter of a data method i.e. (ctx.DataContext.addResource(mLastName, mFirstName, newId, newLastChanged))?. The reason I ask is if a class has many fields it could get a little messy. Would it not be better to pass a dto to the DAL?

Thanks
George

EDIT: P.S. Could you please tell me why you chose to name the concrete implementations (of DAL classes) with the same names as their superclass? For example OrderData : OrderData rather then DTOOrderData : OrderData. I'm just curious :-)

RockfordLhotka replied on Tuesday, January 15, 2008

No, there's no elegant way to do dynamic calls in C#. It is reflection or nothing. You can wrap the reflection in an elegant API I suppose    (and you'd want to, because to get it right like VB or Ruby or whatever requires a lot of code - a lot of type checking, dealing with edge conditions, type coercion, etc).

PTrackerDataContext and SecurityDataContext are created by the LINQ to SQL (L2S) support in Visual Studio 2008. In fact the entire ProjectTracker.DalLinq assembly was created using drag-and-drop in VS 2008 - I did no coding or modifications to anything there.

This also means I didn't create the DTOs. They were created automatically as part of the dbml file. Their naming is entirely as decided by Visual Studio, I just did drag-and-drop.

My original intent was to see how far I could get before needing to do manual work around LINQ. But in the end I was pretty happy with the default code and did no extra work!

The only issue I encountered was the L2S code doesn't like stored procedures that return multiple result sets (like getProject and getResource). I was unable to use those two stored procedures, and had to do direct LINQ statements in Project and Resource. Not a big deal, but it took me a while to understand why I wasn't getting the right child data from my queries when I was using the sprocs.

alef replied on Friday, November 07, 2008

For the multiple results I've found the following article (LINQ to SQL: returning multiple result sets):
http://blogs.msdn.com/swiss_dpe_team/archive/2008/02/04/linq-to-sql-returning-multiple-result-sets.aspx

So it is possible to reuse the SP's getProject and getResource.

RockfordLhotka replied on Friday, November 07, 2008