2009-07-13 7 views
0

Mon projet utilise une page de base pour conserver la fonctionnalité de la page courante. Cela a fonctionné jusqu'à ce que la page de base devienne énorme, alors j'ai essayé de factoriser la page de base en plusieurs classes. Ensuite, je me suis aperçu que je ne peux pas écrireComment simuler l'héritage multiple pour les pages de base ASP.NET?

public MyPage : SecurePage, PageWithGridViewSorting, PageWithSessionWarning 

donné quelque chose comme:

public class SecurePage : RadAjaxPage 
{ 
    // Add session id to ViewStateUserKey 
} 

public class PageWithGridViewSorting : RadAjaxPage 
{ 
    // add sorting to all grids on page 
} 

public class PageWithSessionWarning : RadAjaxPage 
{ 
    // inject javascript to warn user of impending session end 
} 

Quel chemin dois-je prendre cela? Et je pense que le fait que ce soit la page ASP.NET est pertinent car c'est une classe qui est construite par le framework, pas moi. Ma première pensée a été de faire un override pour le constructeur et passer dans les fonctionnalités et cela ne fonctionnera pas avec System.Web.UI.Page.

+0

L'une de ces fonctionnalités est-elle accessible à partir d'autres classes? Si c'est le cas, vous instanciez simplement les objets appropriés OU vous leur donnez des classes statiques et appelez des méthodes de cette façon. – Powerlord

+0

@RBembros Généralement, ce code se connecte à Page_Load, OnInit, etc., c'est donc le pipeline ASP.NET qui appelle le code, via les événements et le cycle de vie de la page. Point bien pris pour les méthodes statiques, je suis d'accord que ceux-ci n'ont pas besoin d'être dans une classe de base. – MatthewMartin

Répondre

4

-ce que les fonctions fournies par SecurePage, PageWithGridViewSorting et PageWithSessionWarning réellement besoin d'être surchargé ou supplantée par leurs classes dérivées? Si tout ce que vous faites utilise l'héritage pour les fonctions de groupe, vous devriez envisager d'utiliser une autre méthode d'organisation des fonctions dans les classes. Comme, par exemple, le Strategy pattern. Une page avec tri est une page, avec tri. C'est une page que a le tri. Utiliser l'héritage n'est pas la bonne façon d'aborder ce problème.

Si doivent différer dans les classes dérivées, vous pouvez vouloir aborder le problème avec des interfaces au lieu de l'héritage. Puisque vous allez redéfinir les fonctions de toute façon, cela ne devrait pas augmenter la complexité ou vous faire répéter.

EDIT: Compte tenu des spécificités de votre problème, il me semble vraiment que vous devriez enquêter aspect-oriented programming et comment vous pouvez fit it into your language.

3

Je voudrais essayer de déplacer une partie du contenu de BasePage à UserControls. Disons PageWithSessionWarning. Cela pourrait être un contrôle que vous mettez sur la page maître.

2

Je pense que ASP.NET est un environnement où vous devriez préférer la composition à l'héritage. Vous devriez envisager de restructurer votre code pour «injecter» les fonctionnalités nécessaires en composant votre page à partir des classes auxiliaires qui se connectent aux événements Page et fournissent la fonctionnalité. dans une structure partagée que d'autres pages peuvent utiliser. Cela peut être difficile à faire dans ASP.NET car le cycle de vie de la page est complexe et peut souvent vous gêner pour écrire du code générique.

Vous pouvez également essayer de déplacer la fonctionnalité dans les contrôles personnalisés ou utilisateur si la fonctionnalité est centrée sur l'interface utilisateur.

En outre, les pages maîtres sont un moyen efficace d'affacturage fonctionnalités communes sur une page et

Questions connexes