【发布时间】：2010-03-18 15:33:07
【问题描述】：
背景，我正在使用自定义类和额外的表来扩展 ASP.NET 成员资格。
ASP.NET MembershipUser 有一个受保护的构造函数和一个从数据库读取数据的公共方法。我已经使用自定义表和相关类扩展了数据库结构。
不像原始 API 那样使用静态方法创建新成员：我允许代码实例化一个简单对象并填充数据，因为有多个实体。
原创 模式 #1 受保护的构造函数
> static CreateUser(string mydata, string, mydata, ...)
> User.Data = mydata;
> User.Update()
我的首选 模式 #2 公共构造函数
> newUser = new MembershipUser();
> newUser.data = ...
> newUser.ComplextObject.Data = ...
> newUser.Insert()
> newUser.Load(string key)
我发现模式 #2 使用起来更容易、更自然。但是方法 #1 更加原子化并确保包含正确的数据。
我想听听关于利弊的任何意见。我心中的问题是我更喜欢简单的 CRUD/对象，但我也在尝试利用底层 API。这些方法并不完全匹配。例如，API 有方法，如 UnlockUser() 和 IsLockedOut 的只读属性。
我可以看到有几种可能性。
选项 #1 让对象自己保存/加载，但需要私有构造函数。
选项 #2 让对象自己保存/加载，但让它有一个公共构造函数
选项 #3 一种是创建一个 POCO/简单的 CRUD 对象，然后使用静态方法来更新数据库。 .....
选项 #1 好处：多线程安全“原子”，对象完整性 缺点：难以使用 -> 传递大量数据，可能需要在创建后进行更新，这在某些情况下需要包装在事务中，因此看起来很混乱
选项 #2 优点：易于使用，易于组织交易 缺点：对象可能会或可能不会被正确设置
【问题讨论】：
-
我发现整个会员制真的很不灵活和烦人 - 最后，我从头开始编写自己的内容比尝试破解 ASP.NET 来做我想做的事情要快。例如，在我们的一个系统中，用户没有电子邮件地址，但您必须填写电子邮件地址才能使密码重置等操作生效。并且不要让我开始无法从事物中获得像样的错误消息！
标签： asp.net design-patterns asp.net-membership class-design crud