2011-10-31 10 views
2

私は.NETメンバーシップ・フレームワークでカスタムRoleProviderを実装しています。既存のものは機能的に少し微調整する必要があるので、静的な役割クラスを呼び出すために自分のPublic関数を実装したいと思います。プロバイダーに直接電話するのは悪い習慣と考えられますか?

の代わりに、オブジェクト - >役割 - > RolesProvider 私は、オブジェクトを行くだろう - > RolesProvider

は、これは悪い習慣と見なされるでしょうか?現在のデータベースの唯一の選択肢は、RoleProviderの使用を完全に排除し、認可のために独自のカスタムシステムを実装することです。

編集:わかりやすくするために、私は既にカスタムのMembershipProviderを実装していますので、Membership-フレームワークで作業を続けたいという欲望はかなり高いです。

答えて

2

フレームワークの一部を迂回したり意図しない方法でカスタマイズしたりすると、いつでも悪い練習とみなすことができますRolesクラスを介して現在のプロバイダへのアクセスを容易にすることは、ASP.NETメンバーシッププロバイダフレームワークの意図です。 .netフレームワーク、コンフィグレーション、またはツールの中には、この仮定を行う役割メンバシップ機能の周りに他の領域が存在する可能性があります。そのため、変更後にもはや意味をなさないことがあり、プロジェクトに関係する他の人たちに混乱を招く可能性があります。 ASP.NET Webサイト管理ツールは、この前提を実現するツールの1つの例です。変更後に誰かがこのツールを使用すると、結果としてロールのメンバーシップとサイトが破損する可能性があります。

このアプローチを採用する場合は、追加する機能を慎重に検討し、最終的には本当に必要なのかを尋ねる必要があります。そうであれば、混乱を避けるために完全なカスタムを実装する方が良いかもしれません。

関連する問題