Partially filled-in object

Question

 

I fully understand that the Entiry Framework is an O/RM mapper, designed so you end up with entities which reflect he design of (generally) tables in the database.

 

But I have a scenario in which, for security reasons, different users are not permitted to see certain properties of those tables/objects.

 

So my question is: is there a recommended/good way to stop the object being a 'select * from table', but having a proscribed set of values. What is more complicated is that the set may only be defined at runtime.

 

Of course I have some ideas in my head, but rather than quering the pitch I was wondering if anyone out there would have any recommendations.

 

cheers

 

Matt

Answer 1

So do i understand correct that users can write a query and retrieve data via silverlight?

If this is the case, why dont you just create views, in which you can define which data is displayed to the user.

And then u create an entity model for those views.

Answer 2

(The client isn't necessarily significant, but yes it is most likely to be Silverlight via Ado.Net Data Services).

 

Yes, views are one option.

+ Simple layering using Entity Data Framework more or less unadulterated

- Many, many, many views required

 

Matt

Answer 3

Hi,

 

This can be achieved with views or hiding certain properties exposed on the entities using IgnoreProperties attribute.

 

 

[IgnoreProperties(“Price”)]

public class Automobile

{

       public int AutoMobileId {get; set;}

       

      public double Price {get; set;}

      …

}

 

 

Thanks

 

John

Answer 4

Ok thanks.

But

Searching the web reveals nothing about this, though I do see that it lives in the Syetm.Data.Services namespace.

 

My classes are generated by the Ado.Net entity framework. I assume I would be able to decorate the class by writing a partial class and adding the above attribute, but unfortunately that is not sufficient since I need different variants for different purposes.

 

I have yet to work out how I can create other classes within the service other than those created by the EDM. I think that is what I would need to do to be ablt to turn off properties.

 

 

 

Answer 5

I am unable to get the IgnoreProperties attribute to work.  I have an EDM that does not contain a TempID property.  I would like it to have one (see this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3724064&SiteID=1 ), but currently it does not.

 

I have generated client-side Entity classes using DataSvcUtil.  I have added this code:

 

Code Snippet

namespace SonixtreamModelClient {

[IgnoreProperties("TempID")]

public partial class StationInventory {

public int TempID { get; set; }

}

}

 

 

 

I create a new StationInventory object and save it in the database.  For the code that shows exactly how I'm doing that, see this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3720883&SiteID=1 .

 

When I save this object (using BeginSaveChanges), I get an exception.  The meat of the exception (drilling through inner exceptions) is:

 

Error processing request stream. The property name 'TempID' specified for type 'SonixtreamModel.StationInventory' is not valid.

 

This is coming from the server, ultimately in:

 

System.Data.Services.DataService`1.BatchDataService.HandleBatchContent(Stream responseStream)

 

I then look at the POST request in Fiddler.   Here is the entry object, with some information snipped out for brevity:

 

<entry>

<content type="application/xml">

<m: properties>

<d:Artist>SI(Server): 1:02:23 PM</d:Artist>

<d:TempID>-5</d:TempID>

</m: properties>

</content>

</entry>

 

Note that TempID is included in the data being sent to the server in the POST, even though I flagged the client entity class with the IgnoreProperties attribute.

 

Am I using it incorrectly?

 

Thanks,

 

David Cater

Answer 6

Hi David,

 

I believe that this property only works server side, i.e. add this into a partial class on the server.  When you generate the client side code using datasvcutil it shouldn't contain this property.  The reason for this property is to enable you to access it on the server but not on the client.

 

Hope this makes sense.

 

thanks

 

John

Answer 7

Well, damn.  That doesn't meet my needs at all.  What I really need is a property that:

• Can be set on the client.
• Is transferred to the server during an insert/update.
• Is available to an Interceptor handling the update query.
• Is not stored in the database.

Sounds like I might be S.O.L., but I'm going to keep holding out hope.  This other post explains why I need that, and hopefully I'll get some guidance towards a solution there: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3724064&SiteID=1 .

 

Thanks for the quick response!

 

David

 

Answer 8

Hi David,

 

Oh now I see what your trying to do!  The original ignore properties was to protect the Data Service from potential sensitive data.  What you want is to add a field that doesn't exist on the database but is then passed through.

 

I have a similar requirement on a calculated field that I'm currently working on today!  When I crack it I'll send you the code on this post.

 

thanks

 

John