如何使用 ASP.NET MVC 创建用户数据库
我是 ASP.NET MVC 新手,所以请尽可能明确。
这是我的目标:
我想创建一个简单的网站,用户可以在其中:
- 注册并登录
- 输入联系方式(电话、地址等)
- 查看联系方式
- 编辑 #3 的详细信息。
稍后在网站中,我将创建使用此数据的其他页面,但目前只需要上述项目。
我的问题是,我一直在查看创建新的 ASP.NET MVC 应用程序时出现的默认 ASP.NET MVC 示例。
我试图弄清楚是否应该将 aspnetdb.mdf 数据库中的所有联系人详细信息存储在现有表中,或者应该创建新表。
看来我可以扩展 aspnet_Users 或 aspnet_membership。
请告诉我这些表是否可以扩展以存储其他字段,或者在该数据库中创建一个新表是否更安全。
i am new to asp.net mvc so please be explicit as possible.
Here is my goal:
i want to create a simple website where users can:
- Register and log in
- Enter there contact details(phone, address, etc)
- View there contact details
- Edit details of #3.
Later in the website, i will create other pages that use this data but for now the only items above are needed.
my questions is that i have been reviewing the default asp.net mvc sample that comes when you create a new asp.net mvc app.
I am trying to figure out if i should store all the contact details in the aspnetdb.mdf database in an existing table or i should be creating new tables.
it seems like i could extend aspnet_Users or aspnet_membership.
please let me know if these tables can be extended to store additional fields or if its safer to just create a new table in this database.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以使用 Asp.net 配置文件提供程序 存储信息。 单击链接以获取有关使用内置 SqlProfileProvider 的说明。 默认情况下,SqlProfileProvider 将在 aspnetdb.mdf 文件中创建表,因此您可以将所有内容保留在一处。 您可以将配置文件提供程序作为 HttpContext 上的属性进行访问。
编辑:更好的链接 ASP.Net 配置文件信息
使用配置文件提供程序,您不必担心进行数据库调用或识别当前用户。 这一切都是以您的名义完成的。 仔细检查文档,因为以下内容可能有点不对劲。
您可以在
内的 web.config 中添加所需的字段。 就您而言,这将是必要的联系信息。然后,您可以访问 HttpContext.Profile.Address 等,并且提供程序将负责将所有内容与当前用户绑定。
添加和编辑信息意味着显示表单。 查看详细信息只是显示您从上一个表单帖子中保存的所有字段。
NerdDinner 来源 和 教程非常值得一看。
You could use an Asp.net profile provider to store the information. Follow the link for instructions on using the built-in SqlProfileProvider. By default, the SqlProfileProvider will create tables in the aspnetdb.mdf file, so you can keep everything in one place. You can access the profile provider as a property on the HttpContext.
Edit: Better link for ASP.Net profile information
Using the Profile provider, you don't have to worry about making database calls or identifying the current user. It's all done on your behalf. Double-check the documentation, because the following might be a little off.
You add the fields that you want in your web.config inside
<system.web>
. In your case, it would be the necessary contact information.Then, you can access HttpContext.Profile.Address and so forth and the provider will take care of tying everything to the current user.
Adding and editing the information means displaying a form. Viewing the details is just displaying all the fields you saved from the previous form post.
The NerdDinner source and tutorial are well worth checking out if you're completely new to MVC.
您可能还想查看 SQL Server 发布向导,找到 此处。
它本质上允许您将数据库结构和/或数据复制到 .sql 文件,然后可以将其导入到主 SQL 数据库中。
我不太喜欢 aspnetdb 方法,但这是我个人的观点。
You may also want to take a look at the SQL Server Publishing Wizard found here.
It essentially allows you to copy the database structure and/or data to a .sql file that you can then import into your primary SQL database.
I don't particularly like the aspnetdb approach but that's my personal opinion.
这个问题引起了我内部的一些争论。 我可以看到扩展现有成员资格提供程序以保存必要的附加信息的逻辑,但是如果这是所采用的路径,我只会使用 aspnetdb 数据库来存储此信息,因为在我看来,该数据库的目的是存储由 ASP.NET 通过会员 API 管理的信息
如果您决定不扩展 ASP.NET 现有的会员提供程序,那么我建议创建另一个数据库,或者至少创建一些新表来保存您单独管理的数据来自 ASP.NET 管理的任何其他数据
This question has been the cause of a little bit of an internal debate for me. I can see the logic in extending the existing membership provider to hold the neccessary aditional information, however I would only use the aspnetdb database to store this information if that was the path taken, as the purpose of that database, in my mind, is to store information mamaged by ASP.NET via the Membership API
If you did decide not to extend asp.net's existing membership provider then I would suggest creating another database, or at the very least some new table(s) to keep data you are managing seperate from any other data managed by ASP.NET