views:

44

answers:

3

So I have a data access class library

I make a linq to entities call

I end up with a single row that has my TableData object.

What should I return back from my class library method?

I thought it would be cool to return back the TableData object, but I see that if you make changes to it and call a save that it actually updates the database, which I do not want outside of my class library.

What do people typically return as their results object?

+1  A: 

If you set the status of an EF-tracked object to Detached changes will not be propagated to the database.

Henk Holterman
+2  A: 

If you are trying to follow an n-Tier architecture, my suggestion would be to use the Self-Tracking Entity T4 templates.

  1. Open your .EDMX
  2. Right click somewhere in the enpty space of the visual view of your models and select "Add Code Generation Item"
  3. Select the Self-Tracking template

Then your model would be what you want to return from your repository and the changes you make to your entity would be tracked when you wan to persist them back to the database.

JohnEgbert
A: 

This is a GREAT question becuase to me it really points to the seperation of concerns. On the one hand you want the 'native' data back for examination or whatever. But on the other you might not want all the 'live data baggage'.

This I think is where data-transfer-objects can play a role. I've even gone so far as to define interfaces for DTO's that have read-only properties. 'What I get back' is defined by what I ask for - IDTO, DTO, or Entity-with-logic because some business-layer object can consume the DTO.

I don't use EF but in our own ORM-ish DAL this is exactly how it works - factories and services are generic and return what you asked for. Don't want to worry about editing? Ask for the interface which doesn't have any writable properties.

n8wrl