如何在ASP .NET MVC与用户(客户)的对象列表关联 [英] How to associate list of objects with user(Account) in ASP .NET MVC

查看:758
本文介绍了如何在ASP .NET MVC与用户(客户)的对象列表关联的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想用来存储对象的名单我的应用程序的每个用户。

我想补充一个列表 会议为每个用户对象。当然,我想使这项工作与实体框架

 公共类会议{
    INT标识{获取;设置;}
    人人{获取;集;} //与人会议
    日期时间日期时间{获取;集;}
}

问:我应该将它添加到塔 AccountModels.cs ?我应该在哪里添加这个文件里面呢?它应该是公正和Id的满足与否?或者,也许我需要他们之间的关联类?

我张贴的内容 AccountModels.cs 以下文件。

 使用系统;
使用System.Collections.Generic;
使用System.ComponentModel.DataAnnotations;
使用System.ComponentModel.DataAnnotations.Schema;
使用System.Data.Entity的;
使用System.Globalization;
使用System.Web.Security;命名空间OdeToFood.Models
{
    公共类RegisterExternalLoginModel
    {
        [需要]
        [显示(名称=用户名)]
        公共字符串用户名{获得;组; }        公共字符串ExternalLoginData {搞定;组; }
    }    公共类LocalPasswordModel
    {
        [需要]
        [数据类型(DataType.Password)
        [显示(NAME =当前密码)]
        公共字符串OldPassword更改{搞定;组; }        [需要]
        [StringLength(100,的ErrorMessage ={0}必须至少{2}字符长。,MinimumLength = 6)]
        [数据类型(DataType.Password)
        [显示(NAME =新密码)]
        公共字符串NEWPASSWORD {搞定;组; }        [数据类型(DataType.Password)
        [显示(NAME =确认新密码)]
        [比较(新密码的ErrorMessage =新密码和确认密码不匹配。)
        公共字符串ConfirmPassword {搞定;组; }
    }    公共类LoginModel
    {
        [需要]
        [显示(名称=用户名)]
        公共字符串用户名{获得;组; }        [需要]
        [数据类型(DataType.Password)
        [显示(NAME =密码)]
        公共字符串密码{搞定;组; }        [显示(NAME =记得我吗?)]
        公共BOOL了rememberMe {搞定;组; }
    }    公共类RegisterModel
    {
        [需要]
        [显示(名称=用户名)]
        公共字符串用户名{获得;组; }        [需要]
        [StringLength(100,的ErrorMessage ={0}必须至少{2}字符长。,MinimumLength = 6)]
        [数据类型(DataType.Password)
        [显示(NAME =密码)]
        公共字符串密码{搞定;组; }        [数据类型(DataType.Password)
        [显示(NAME =确认密码)]
        [比较(密码的ErrorMessage =密码和确认密码不匹配。)
        公共字符串ConfirmPassword {搞定;组; }
    }    公共类ExternalLogin
    {
        公共字符串提供商{搞定;组; }
        公共字符串ProviderDisplayName {搞定;组; }
        公共字符串ProviderUserId {搞定;组; }
    }
}


解决方案

我真的希望微软将使得其默认MVC项目模板,以便更好地阐明正确的MVC开发一些改进,但是这似乎并没有发生。

一般情况下,你希望每个类一个文件。有没有技术上的原因,但它使你的code工作要容易得多。例如,你的会议类会去在 Meeting.cs 文件,然后你不必怀疑那里的AT。你知道去寻找同名的文件。

然后, AccountModels.cs 其实大多含有的视图模式的(仅视图MVC5车型,实际上,我也注意到,微软改进了这一通过命名文件MVC5 AccountViewModels.cs )。术语模式是围绕在ASP.NET MVC pretty松散抛出。你的实体框架支持类或波苏斯,实际上是什么所谓的实体(因此实体框架),实体基本上是一个DTO或数据传输对象,是不是真的适合被用作模式的。视图模型是用于重新present的图的某些功能的类。在的形式的情况下,通常最终被正在创建或更新的实体的传真​​机,但它们可以更远到达并具有比是适当添加到实体在大多数情况下,更多的业务逻辑。

您唯一的实体默认项目模板,pre-MVC5,为用户配置。我居住在同一个 AccountModels.cs 文件与应用程序的默认背景下沿, UsersContext 。在这个文件中每个类的分割成他们自己的档案,这将是更为合适: UserProfile.cs UsersContext.cs

在MVC5,你唯一的实体是 ApplicationUser ,而这又是摆在 IdentityModels.cs 不佳,文件这也包括你的应用程序的默认生成的上下文。这将是好得多,如果这些被剥离出来,放入 ApplicationUser.cs ApplicationDbContext.cs 文件。

不管怎么说,典型的布局是同时拥有模式目录和的ViewModels 目录。实体走在模式目录(大多是出于习惯,因为再次,他们是不是真的适合模式),显然查看模式走在了的ViewModels 目录。我通常会要么把我的情况下伸到根,如果它是一个简单的项目或创建一个单独的目录只是为了环境,如果我要拥有​​比只有一个(连接到多个数据库)以上。

同样,这是所有可选。事实上,你可以做任何你想要的,但遵循一些这些事情使有工作和维护你的项目更简单,也更容易为其他开发人员拿起你离开了。

更新

这并没有真正回答你的问题,这似乎是你如何关联应该有一个会议你的用户级(用户配置 / ApplicationUser 根据MVC你的工作版本)。

的第一步总是以确定两个事物之间的关系的性质。它是一对吗?一到多少?多到多少?我不能为你的应用程序说话,但会议看起来的喜欢它应该是多到多:一个用户可以有很多次会议,会议可能有很多用户。在这种情况下,你只会设置在两侧的集合:

用户配置/ ApplicationUser

  public虚拟的ICollection<会议>会议{搞定;组; }

会议

  public虚拟的ICollection<用户配置>与会者{搞定;组; }

或者

  public虚拟的ICollection< ApplicationUser>与会者{搞定;组; }

这足以实体框架沟通,这是一个多一对多的关系,它会自动在后台创建一个中间表来跟踪。

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; }
    }
}

解决方案

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.

这篇关于如何在ASP .NET MVC与用户(客户)的对象列表关联的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆