2

I'll try to be short and clear with this question.

We have an asp.net mvc app that uses entity framework 4.

Our business model is relatively straightforward: We have an object (which corresponds to a table) called Photo(s). That photos table has a handful of columns that match up to properties on the object. Description,Title,Date etc. It also has a number columns that reference foreign keys for other tables: AuthorId,LicenseId etc...

The author and license tables are complex in their own right, with multiple fields (Title,Summary,Date etc.)

I have multiple clients using this application to view their photos. I would like each client to dictate what fields they see when viewing the photos, as well as what fields they see when editing those fields.

My thought is to have tables setup saying client-a should see Field1,Field2 and Field3 when viewing their photos - and client-b should see Field1,Field4 and Field5. But some of these fields are not simply columns in the main photos table, they may be fields in a child table. so Field1 might be: Table.Photos.Title -> which corresponds to an object as: Objects.Photo.title... but Field3 might be: Table.Licenses.LicenseSummary -> which corresponds to an object as: Objects.Photo.License.LicenseSummary

I'm trying to figure out the methodology that we would use to have a very data driven environment so in the DB I can say, display this object/property (for viewing or editing) and then it would know how to map to whatever table it needs to pull that information. also, during editing... give it some way to pull a list of available values if it is that type of property, and not just a text field.

I'm looking for an example of what this might involve, our model is actually more complex than this, but this is just an idea of what we are trying to accomplish. I don't know if what I'm trying to do is normal, perhaps it involves reflection? This is a new area for me.

tereško
  • 58,060
  • 25
  • 98
  • 150
TheRedDwarf
  • 183
  • 1
  • 13
  • Do the clients define their own custom fields? – Robert Harvey Mar 27 '13 at 16:12
  • @DavidePiras - it doesn't, I can learn from that in terms of how to properly structure an N-Tier application, but that's not what i'm looking for. – TheRedDwarf Mar 27 '13 at 16:15
  • @RobertHarvey, yes - but we handle that in a different way. It's more that we have a lot of "standard" fields for them to choose from, and some of them are more complex than others. Especially when dealing with things like security/security groups. – TheRedDwarf Mar 27 '13 at 16:17
  • The title is about inserts and updates, the question seems to focus more on viewing. So do you want to cover the whole CRUD spectrum? Anyhow, this is not trivial. It entails building queries dynamically, including joins. Probably better suited for a textual approach, like basic DbCommands (with Dapper?) and using system tables to get table and column names. Even the types to capture the query results in can not be statically defined. – Gert Arnold Mar 27 '13 at 18:36

1 Answers1

0

If the clients are defining their own custom fields, I would simply give them a Key/Value pairs table.

PhotoID    FK
Key        string
Value      string
Display    bool

Note that this essentially amounts to EAV, which comes with its own set of difficulties.

If it's just about permissions on existing fields, you need to capture that information:

PhotoID    FK
ClientID   FK
FieldName  string
Display    Bool

You can use this information to inhibit the display of fields in the View. The easiest way to do that would be to use a loop in the View itself, writing the field to the output only if Display is set to true.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • I appreicate your input, it's less to do with the customization of fields - as I said, we have a process for this (like what you're doing). It's more that we have a number of static db fields over various tables that we need to be able to access/view and pull lists of values from with editing. the more I think about it, I'm wondering if maybe I should just hard code some of this in the DB like - if they're editing the field "LICENSE", I will have to look for that specifically in code and do what we need to allow them to edit the license for that photo. – TheRedDwarf Mar 27 '13 at 16:24
  • my thought was we might add more static fields to the table, and I didn't want to have to update the code to handle those fields. but maybe that is just what I should be doing... – TheRedDwarf Mar 27 '13 at 16:24
  • There should be a way to get the field name from the model, so that you can match it up with the permissions table and your solution will still work if you add a field later. Something like this: http://stackoverflow.com/questions/6615541 – Robert Harvey Mar 27 '13 at 16:28