ASP.NET MVC 论坛应用程序答案

【问题标题】：ASP.NET MVC Forum ApplicationASP.NET MVC 论坛应用程序
【发布时间】：2009-11-06 18:00:09
【问题描述】：

我需要为朋友的网站编写一个论坛应用程序。我想用 C# 3.0 编写它，针对 ASP.NET MVC 框架，使用 SQL Server 数据库。

所以，我有两个问题：

我应该使用 Linq to SQL 还是实体框架作为数据库抽象？
我应该使用 ASP.NET Membership API 还是添加 Users 表并自己实现？

谢谢。

【问题讨论】：

标签： asp.net-mvc linq-to-sql asp.net-membership forum

【解决方案1】：

在 Internet 上有很多将 ling 与 ASP.NET MVC 结合使用的示例。但也许你可以添加你的列表 NHibernate。如果您不想添加我建议使用实体框架。使用 ORM 是一个优点。
我一直选择编写自己的会员管理层。如果您喜欢（编写自己的代码并在将来进行更改时感到高兴。）编写自己的会员层。如果您正在寻找快速解决方案，ASP.NET Membership API 是一个不错的选择。

【讨论】：

【解决方案2】：

肯定是实体框架 -- 见下文。
ASP.net Membership API -- 易于维护。

原因： Entity Framework vs LINQ to SQL

【讨论】：

【解决方案3】：

1) 两者如何？只需创建一个抽象，您就可以使用其中任何一个。我的建议是使用存储库模式。

2) 会员供应商有其优势和劣势。对于某些项目，它对于我的需求来说太复杂了。但是，如果您需要在短时间内运行某些东西，那就太好了。

【讨论】：

我认为 1 对于这样的事情是不必要的抽象，除非您计划将该组件作为其他项目的平台分发。
不确定在使用数据库时是否存在不必要的抽象。这很容易做到，并且易于维护。不知道为什么你不同意......你并没有在这里真正说明问题......
更多的代码并不意味着容易维护。抽象层始终是代码膨胀和灵活性之间的权衡。如果您在不需要灵活性的情况下，剩下的就是更多的代码来编写、调试和维护。可能我做过的 99% 的事情都没有改变持久性的故事，或者如果他们这样做了，那是在完全重写的过程中。如果实际需要灵活性（例如分发入门工具包的情况，人们在您的东西上构建），那么抽象出来是有意义的。如果没有，那只是额外的工作。
这不是抽象的重点。你不测试抽象。这是很基本的东西。不使用抽象会导致可维护性问题。在这个人的情况下，他们不太确定他们将使用哪个来实现持久性。在他的情况下，使用抽象在世界上都是有意义的。在这种情况下，紧密耦合的代码维护起来并不愉快。相信我，我做到了！

【解决方案4】：

我不会回答第一个问题，因为我是 nhibernate 的粉丝对于第二个问题，添加用户表并自己实现会员资格，我认为您至少不能以正确的方式做到这一点（很多人试图制作自己的会员资格 api，但他们搞砸了！）

【讨论】：

【解决方案5】：

1) 完全取决于事情的复杂程度。如果您想要一个或多或少以 1:1 方式反映您的表格的快速 DAL，请选择 L2S（或者如果您想要更成熟和受支持的东西，则选择 SubSonic）。如果您想要更多的 n 层类型的东西，而您的表和域模型完全不同，请选择像实体框架这样的 OR/M（或者 NHibernate，如果您想要在各个方面都更好的东西）

2) ASP.net 成员资格极其复杂，其中有些部分设计得很差。但是，这取决于您对这些东西有多少经验。如果您足够了解如何采取措施来避免会话固定攻击，那就自己动手吧，因为它可能会比罐装解决方案更好。如果您不知道那是什么，请花点时间了解默认的。

【讨论】：

【解决方案6】：

想一想，SubSonic 3 是一个非常强大的数据访问生成工具。据我了解，它基本上将 Linq to Sql 包装在一些非常有用的包装器中，并使 Linq 的使用更加直观。使用 SubSonic 时，您可以立即构建一个非常强大的应用程序。不过有个小问题，如果您使用共享主机（比如 GoDaddy），您将遇到中等信任问题。在这种情况下，您可以随时回退到 Linq To Sql，而无需对代码库进行很多更改。

至于 Aspnet_Membership。就它提供的工具数量而言，我建议使用它。

祝你好运，希望这会有所帮助。

【讨论】：