Hi all, I've decided to start another thread for my old health app https://www.daniweb.com/web-development/aspnet/threads/496278/building-first-mvc-application as the old thread was pretty confusing and didn't lead me anywhere. With the knowlegde coming from developing the previous simple book review app here https://www.daniweb.com/web-development/aspnet/threads/497464/much-simpler-first-mvc-application I've also decided to take a different approach: I'll build the app as I go along, meaning, I'll start very simple (two classes minimum) and then I'll continue to update the app and develop the other classes as needed (thanks to @djjeavons now I know I to do successful migrations so databases shouldn't be a problem!).
So, I said I'll start simple. Here is the first two classes of the app, Patient.cs and Jab.cs.

public class Patient
        public int PatientID { get; set; }//primary key
        public string Name { get; set; }
        public string Surname { get; set; }
        public DateTime DOB { get; set; }
        public string Sex { get; set; }
        public double Height { get; set; }
        //public double Weight { get; set; } //this will have its own class
        public virtual ICollection<Jab> Jabs { get; set; }


public class Jab
        public int JabID { get; set; }//primary key
        public int PatientID { get; set; }//foreign key
        public string Name { get; set; }
        public DateTime Date { get; set; }
        public int ShotNumber { get; set; }//which shot is that?
        public string Note { get; set; }//in case I need to add some notes to the jab
        public virtual ICollection<Patient> Patients { get; set; }

A few things to note:
-From research and (small) practice, I now know that I don't need to use [key] or [foreignKey] tokens as MVC is smart enough to determine those on its own.
-A patient can have multiple jabs (one-to-many) and a jab can be done for multiple patients (one-to-many), so both classes keep track of this by using ICollection:
public virtual ICollection<Patient> Patients { get; set; }
public virtual ICollection<Jab> Jabs { get; set; }

Next step will be for me to create the db class, add the below to it:

public DbSet<Patient> Patients { get; set; }
public DbSet<Jab> Jabs { get; set; }

Then I have a question about controllers: what I'd do, is to add two controllers with EF, (the Patient and the Jabs ones), but do you think that is a good approach considering that my model will expand to include other classes (meaning that presumably I will have to have extra controllers as the model grows)?

Before going ahead, I was wondering, is there anything else anybody thinks it is a good idea/practice to add?

OK I've done the usual things, as above, but something odd happened: the app displays OK (I haven't done any CSS changes but that will come soon) except for the fact that when I navigate to the Jab page I get something I shouldn't get, a PatientID field, see screenshot here http://s7.postimg.org/8vhezu0sr/jab.png
That PatientID should be a foreign key, so why is it appearing on the page?!

Maybe because Jab.PatientID is an int instead of a class.

Badly formulated. Since the classes have an N-M relation, do you really need that PatientID? Isn't it generating a link table?

Oh I see, I didn't know that, I thought that a foreign key was always invariably needed to link tables, and if we remove it how does a jab object keeps track of which patient it belongs to? I'll remove it from the jab class then and will see what happens :-)

pritaeas, when you said

Isn't it generating a link table

did you mean that my code, well the patientID, was generating a third table? I looked at the table generated and in fact I don't see two tables as I expected to see, but three (the extra one being JabPatient):

So, removing the PatientID will effectively remove the table. Now, could you please explain in layman terms why in a many-to-many relationship the patientID field adds an extra table and it doesn't do that if the relationship is one-to-many?

If you have a one-to-many relationship two tables are enough to define it. Suppose a patient can have multiple jabs, adding a patient id to a jab suffices.

Since you have defined that a patient can have many jabs, but also that a jab can have many patients, the only way to define that is by having a link table. The link table's only purpose is to connect any patient with any jab, thus consisting only of a patient id and a jab id.

There is no clean way to define a many-to-many relationship with just two tables. Technically, you can use a column in each table containing comma separated values, but that makes joins and selects all the more difficult.

If you write it out on paper you'll see the necessity of the link table.


pritaeas, sorry for the slow reply, been away with no access to my laptop.
Thanks for clarifying things and for the link. I had a look and it makes sense to a point, but when I tried to draw it - even taking this http://www.entityframeworktutorial.net/images/entityrelation2.png into consideration I couldn't really assign this link table with the primary keys any functionality, but I guess it's OK, in the sense I still don't fully appreciate it... You did explain it in your post though, so let me try to clear this up, well for me at least. Say PatientA has Jab 1 and 2 and that PatientB has Jab 1,2 and 3: what data ends up in the JabPatient table? Surely the ID of PatientA and PatientB (under the PatientID column) but what under the JabID column?
Going back to my application: I do understand that this link or joining table is important and that it gets the primary keys of both classes, hence the name JabPatient in my case. Going back to what you said at the beginning of the thread, I did notice that, in the courses and students example, class Course doesn't not contain any reference to the studentID: in my case, as you've mentioned, I then don't need the Jab class to have any PatientID because the many to many relationship is created by defining this in the Jab class public virtual ICollection<Patient> Patients { get; set; } and this one public virtual ICollection<Jab> Jabs { get; set; }in the Patient class, this is pretty clear. Essentially that PatientID is redundant, but why, if I leave it in - and I won't of course - does it come up as a visible field in the application? Just curious, but I'm more keen to understand exactly what data goes into the JabPatient joining table
thanks for your help

PatientA has Jab 1 and 2 and that PatientB has Jab 1,2 and 3: what data ends up in the JabPatient table?

The link table would contain the following, A and B instead of the real ID's in this case:

PatientId  JabId
A          1
A          2
B          1
B          2
B          3

AH OK I seem so essentially this link table keeps track of which patient is associated with which jab. OK got it.

looking at the discussion this is relatted to ORM and data linking ...so mvc and entity framework would resolve this.. you can refer Click Here for more details..

you can refer Click Here for more details

And how exactly does a very global overview answer this question? (Ignoring the fact that EF/MVC is already used.)