编程到接口 - 将它们用于安全类?

时间:2009-01-23 17:11:21

标签: c# asp.net interface

好的,我已经阅读了Stack Overflow问题'What does it mean to "program to an interface"'并了解它。我理解使用接口的好处(至少我认为我这样做)。但是,我在将其应用于我目前正在进行的工作时遇到了一些问题,这将是我的第一个接口实现。

我正在创建一个类来验证我的网站的用户。我用静态方法编写它,所以我可以做User.Authenticate(用户名,密码)。对我来说,这很好,很容易。展望未来,将有3种其他类型的成员可以进行身份​​验证。他们的身份验证方法将指向不同的表等。但是,他们仍然需要进行身份验证,更改密码,更改密码以验证其安全问题等。这似乎是一个完美的用于界面但我有围绕着如何做到这一点的问题。

用户类型是用户,医生,经纪人,雇主。对我来说,每个类都应该实现一个定义上述方法的安全接口。

如果我的想法是对的,那么有人可以解释如何做到这一点吗?

7 个答案:

答案 0 :(得分:2)

您可能需要查看ASP.NET/Microsoft Membership。从您的描述中可以看出,您拥有不同角色的用户(医生,经纪人等)。

答案 1 :(得分:1)

“编程到接口”意味着设计一组方法和属性,这些方法和属性是该类将提供的功能或服务的公共“签名”。

您将其声明为接口,然后在实现接口的类中实现它。

然后要替换该类,可以使用任何其他实现该接口的类。

界面成为合约。

但是,这不适用于静态方法。

我不确定您的User.Authenticate(username, password)服务的目的是什么 - 它是否返回一个值以表明用户已通过身份验证?什么是未经身份验证的用户对象?

您可能有某种中央身份验证控制器对用户进行身份验证,然后根据用户返回不同类别的对象。每个类都将实现(或者可能从用户类继承)公共功能的用户界面,然后使用其特定功能进行扩展。

我不确定这个示例是继承或接口实现的好例子,它实际上取决于我们没有的更多设计细节。

答案 2 :(得分:1)

在我看来,用户类不应该封装安全功能。安全框架或子系统应对各种类型的用户进行身份验证。话虽这么说,您可能希望子系统接受将要进行身份验证的用户的对象。如果是这种情况,那么让每个用户类实现ILogon或类似的接口,至少作为“标记”接口,将允许您的框架在设计时限制参与者类。

一般来说,除非它只是一个标记接口,否则我不会实现一个接口,其实现本身违反了支持继承和多态的体系结构的本质。

答案 3 :(得分:1)

如果您有三个不同的用户对象用于对具有相同方法和属性的用户进行身份验证,那么这将是一个很好的位置,可以添加和连接每个用户对象,并通过它们对其余的交互进行编码。

Cade对于无法将接口应用于静态方法是正确的。主要原因是接口应用于实例化对象,静态方法不属于该对象。

//Defined Classes
class UserType1 : SecurityInterface
class UserType2 : SecurityInterface
class UserType3 : SecurityInterface

//Use classes
SecurityInterface authentication = GetCorrectUserTypeObject(); //the methds gets the correct UserType object base on who is supposed to authenticate.

authentication.DoAuthenticate(); 

答案 4 :(得分:1)

我从数据库的角度重新思考你的设计。在我看来,从身份验证的角度来看,所有这些类型的个体几乎都是相同的,除了它们在系统中可能具有不同的角色。我建议更好的方法来处理这种情况可能是拥有用户和角色而不是每种用户的不同表。然后,您将身份验证和授权功能拆分为不同的类,但您只需要一个类进行身份验证。您需要第二个身份验证类的唯一情况是,您的用户是针对不同的身份验证存储(例如SQL或AD,而不仅仅是SQL)进行身份验证的。

我知道这个答案没有解决你的界面问题,所以我要补充一点,我建议你定义一个身份验证接口(或使用MembershipProvider)然后构造一个实现该接口的类。如果您选择这样做,它将以这种方式更容易测试/模拟,并为将来扩展到其他身份验证商店提供必要的基础。

答案 5 :(得分:0)

安全性是我的一个交叉问题,这意味着面向方面的编程。

答案 6 :(得分:0)

您提到的所有类型的用户都是用户。我曾经在很多网站上工作,这些网站采用了一种简短的选址方法,在这种方法中,他们将网站编写的第一类用户视为“用户”,然后后来添加的任何其他类型的用户都被笨拙地捣乱。

我的建议:不要给你的某个用户“用户”打电话。他们都是不同类型或角色的用户。