How to associate list of objects with user(Account) in ASP .NET MVC

Question

I would like to store a List of objects for every User of my application.

I would like to add a List of Meeting objects for every user. Of course I would like to make this work with Entity Framework

public class Meeting{
    int Id {get;set;}
    Person Person {get;set;}//Meeting with person
    DateTime DateTime{get;set;}
}

Question: Should I add this to tha AccountModels.cs? Where should I add it inside this file? Should it be just and Id of meeting or not? Or maybe I need association class between them?

I post contents of the AccountModels.cs file below.

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity;
using System.Globalization;
using System.Web.Security;

namespace OdeToFood.Models
{
    public class RegisterExternalLoginModel
    {
        [Required]
        [Display(Name = "User name")]
        public string UserName { get; set; }

        public string ExternalLoginData { get; set; }
    }

    public class LocalPasswordModel
    {
        [Required]
        [DataType(DataType.Password)]
        [Display(Name = "Current password")]
        public string OldPassword { get; set; }

        [Required]
        [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
        [DataType(DataType.Password)]
        [Display(Name = "New password")]
        public string NewPassword { get; set; }

        [DataType(DataType.Password)]
        [Display(Name = "Confirm new password")]
        [Compare("NewPassword", ErrorMessage = "The new password and confirmation password do not match.")]
        public string ConfirmPassword { get; set; }
    }

    public class LoginModel
    {
        [Required]
        [Display(Name = "User name")]
        public string UserName { get; set; }

        [Required]
        [DataType(DataType.Password)]
        [Display(Name = "Password")]
        public string Password { get; set; }

        [Display(Name = "Remember me?")]
        public bool RememberMe { get; set; }
    }

    public class RegisterModel
    {
        [Required]
        [Display(Name = "User name")]
        public string UserName { get; set; }

        [Required]
        [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
        [DataType(DataType.Password)]
        [Display(Name = "Password")]
        public string Password { get; set; }

        [DataType(DataType.Password)]
        [Display(Name = "Confirm password")]
        [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
        public string ConfirmPassword { get; set; }
    }

    public class ExternalLogin
    {
        public string Provider { get; set; }
        public string ProviderDisplayName { get; set; }
        public string ProviderUserId { get; set; }
    }
}

Answer 1

I really wish Microsoft would make some improvements to their default MVC project template to better elucidate proper MVC development, but that doesn't seem to be happening.

Generally, you want one file per class. There's no technical reason for this, but it makes working with your code much easier. For example, your Meeting class would go in a Meeting.cs file, and then you don't have to wonder where it's at. You know to look for the file of the same name.

Then, AccountModels.cs actually mostly contains view models (only view models in MVC5, and actually, I did notice that Microsoft improved this in MVC5 by naming the file AccountViewModels.cs). The term "model" is thrown around pretty loosely in ASP.NET MVC. Your Entity Framework-backed classes, or POCOs, are actually what's called "entities" (hence "Entity Framework"), an entity is basically just a DTO, or data transfer object, and isn't really appropriate to be used as a model. View models are classes that are used to represent some functionality of a view. In the case of forms, that usually ends up being a facsimile of your entity being created or updated, but they can be farther reaching and have more business logic than is appropriate to add to an entity in most cases.

Your only "entity" in the default project template, pre-MVC5, is UserProfile. I resides in the same AccountModels.cs file, along with your application's default context, UsersContext. It would be far more appropriate to split each of these classes in this file into their own files: UserProfile.cs, UsersContext.cs, etc.

In MVC5, your only entity is ApplicationUser, which again is poorly placed in IdentityModels.cs, a file that also includes the default generated context for your application. It would be much better if these were split off into ApplicationUser.cs and ApplicationDbContext.cs files.

Anyways, the typical layout is to have both a Models directory and a ViewModels directory. Entities go in the Models directory (mostly out of convention, because again, they aren't really appropriate "models") and obviously view models go in the ViewModels directory. I'll normally either move my context out into the root if it's a simple project or create a separate directory just for contexts if I'm going to have more than just one (connecting to multiple databases).

Again, this is all optional. In truth, you can do whatever you want, but following some of these things makes working with and maintaining your project much simpler and also makes it easier for other developers to pick up where you leave off.

UPDATE

That didn't really answer one of your questions, which seems to be about how you should associate Meeting with your "user" class (UserProfile/ApplicationUser depending on your working version of MVC).

The first step is always to determine the nature of the relationship between the two things. Is it one-to-one? One-to-many? Many-to-many? I can't speak for your application, but Meeting seems like it should be many-to-many: a user could have many meetings and a meeting could include many users. In that case you would simply setup a collection on both sides:

UserProfile/ApplicationUser

public virtual ICollection<Meeting> Meetings { get; set; }

Meeting

public virtual ICollection<UserProfile> Attendees { get; set; }

Or

public virtual ICollection<ApplicationUser> Attendees { get; set; }

That is enough to communicate to Entity Framework that this is a many-to-many relationship and it will automatically create an intermediary table behind the scenes to track that.