1

I have a very basic student model property,

public int ID { get; set; }

which is auto incrementing and identity. I want to add more value with it. Which will end up like,

department id + batch id + its own auto-incremented value

Should I disable its identity? I want it to be auto generated. How can I handle that and where (Model, View or Controller)?

Abbas Amiri
  • 3,074
  • 1
  • 23
  • 23
Onick Ahmed
  • 91
  • 1
  • 15

2 Answers2

0

You can't update pmk in EF

You should never update the pmk of a table anyway. If you want to auto generate a pmk for a field, simply use a random number for each student.

Community
  • 1
  • 1
Noah Hall-Potvin
  • 187
  • 1
  • 10
  • Using a random number to generate a key for an object will work for a short time but will create collisions with greater frequency as the table grows. Probably not the best solution here. – ohiodoug Dec 23 '15 at 20:40
  • that's what i was thinking too @ohiodoug – Onick Ahmed Dec 23 '15 at 20:50
0

There are a couple of approaches you could take with designing your table...

One would be to remove the auto increment and add your own value to the record.

Pros: You have full control over the id you're going to insert.

Cons: Concurrency is going to be an issue in that another process could have already written the ID you are about to write. Also you'd still have to keep a running counter somewhere or parse existing record ids.

Another approach is to create an additional identifier field on your table that you can populate based on the combined values you want.

Pros: The database is handling the incrementing identity fields for you. Cons: You will have to make more than one call to the database to insert a new record. Assuming the deptid and batchid are not in the table (so you can't use a trigger) then you'll have to insert, get the identity, then run an update statement to populate the new identifier field.

Of course, you can always have Departments and Batches in separate tables with foreign keys in your Students table. The data is still preserved and you can use joins for reporting or whatever you need rather than parsing out identifier fields.

As for where this code belongs... that depends on the architecture of your application. If you have a nice repository then you could encapsulate that logic within your insert/create function. If not, then I'm afraid the controller is probably where you're going to have to keep this logic, which will be a little messy.

Hope this helps and good luck!

ohiodoug
  • 1,493
  • 1
  • 9
  • 12
  • well thank you. if I create an additional field to bind those id, which will be the best place to do it? is it the controller? should I use a var and assign those data and save it with the others? – Onick Ahmed Dec 23 '15 at 20:37
  • If you create the field in this manner you'd have to first insert your record, then update your model again to populate the second identifier field. Certainly not awesome but if you don't have a lot of inserts, you likely won't notice much, if any, of a performance issues. If you don't have a manager or repository to help wrap your operations then the controller action is where you're left doing this logic. – ohiodoug Dec 24 '15 at 01:18
  • Get your feet wet by using the controller action for now and then go back and read about various architecture patterns and see how you could refactor to abstract this logic away a little better. – ohiodoug Dec 24 '15 at 01:20