IList.Cast<typeof(T)>() renvoie une erreur, la syntaxe semble correcte

StackOverflow https://stackoverflow.com/questions/43126

Question 

public static IList<T> LoadObjectListAll<T>()
{
    ISession session = CheckForExistingSession();
    var cfg = new NHibernate.Cfg.Configuration().Configure();
    var returnList = session.CreateCriteria(typeof(T));
    var list = returnList.List();
    var castList = list.Cast<typeof(T)>();
    return castList;
}

Donc, j'obtiens une erreur de construction lorsque je convertis l'élément "list" en un IList générique....quelqu'un peut-il voir une erreur flagrante ici ?

Était-ce utile?

La solution

T n'est pas un type ni un System.Type. T est un paramètre de type. typeof(T) renvoie le type de T.Le typeof l'opérateur n'agit pas sur un objet, il renvoie le Type objet d'un type. http://msdn.microsoft.com/en-us/library/58918ffs.aspx

@John a raison de répondre à votre question directe.Mais le code NHibernate est un peu décalé.Vous ne devriez pas configurer le ISessionFactory après obtenir le ISession, Par exemple.

public static T[] LoadObjectListAll()
{
    var session = GetNewSession();
    var criteria = session.CreateCriteria(typeof(T));
    var results = criteria.List<T>();
    return results.ToArray();        
}

Autres conseils

Je pense 

var castList = list.Cast<typeof(T)>();

devrait être 

var castList = list.Cast<T>();

@Jon limjap L'erreur la plus flagrante que je puisse voir est qu'un IList est définitivement différent d'un IList<T>.Un IList est non générique (par exemple, ArrayList).

La question initiale utilisait déjà un IList<T>.Il a été supprimé lorsque quelqu'un a modifié le formatage.Probablement un problème avec Markdown.

Corrigé maintenant.

L'IList est un IList<T>, il vient d'être supprimé par une démarque lorsqu'elle l'a publié.J'ai essayé de le formater, mais j'ai raté l'échappement du <T>..Correction de ce problème maintenant.

La CLI ne prend en charge que les arguments génériques pour la covariance et la contravariance lors de l'utilisation de délégués, mais lors de l'utilisation de génériques, il existe certaines limitations. Par exemple, vous pouvez convertir une chaîne en un objet afin que la plupart des gens supposent que vous pouvez faire la même chose avec List vers une liste, mais vous ne pouvez pas faire cela car il n'y a pas de covariance entre les paramètres génériques, mais vous pouvez simuler la covariance comme vous pouvez le voir dans cet article.Cela dépend donc du type d'exécution généré par la fabrique abstraite.

Cela se lit comme une chaîne de Markov...Bravo.

T est déjà un paramètre de type, vous n'avez pas besoin d'appeler typeof dessus.TypeOf prend un type et renvoie son paramètre de type.

"La question initiale utilisait déjà un IList<T>.Il a été supprimé lorsque quelqu'un a modifié le formatage.Probablement un problème avec Markdown."

C'est ce que j'ai vu mais il a été édité par quelqu'un et c'est la raison pour laquelle j'ai mis mon explication sur la covariance mais pour une raison quelconque, j'ai été noté -1.

Vous avez trop de variables temporaires qui prêtent à confusion

au lieu de

var returnList = session.CreateCriteria(typeof(T));
var list = returnList.List();
var castList = list.Cast<typeof(T)>();
return castList;

Fais juste

return session.CreateCriteria(typeof(T)).List().Cast<T>();

@Jonathan Hollande

T est déjà un paramètre de type, vous n'avez pas besoin d'appeler typeof dessus.TypeOf prend un type et renvoie son paramètre de type.

typeof "prend" un type et renvoie son System.Type

La CLI ne prend en charge que les arguments génériques pour covariance et contravariance lorsque vous utilisez des délégués, mais lorsque vous utilisez des génériques, il existe certaines limitations, par exemple, vous pouvez convertir une chaîne en un objet afin que la plupart des gens supposent que vous pouvez faire la même chose avec List<string> à un List<object> mais vous ne pouvez pas faire cela car il n'y a pas de covariance entre les paramètres génériques. Cependant, vous pouvez simuler la covariance comme vous pouvez le voir ici article.Cela dépend donc du type d'exécution généré par la fabrique abstraite.

@Jon et @Jonathan sont corrects, mais vous devez également modifier le type de retour en

IList<T>

aussi.À moins que ce ne soit juste un bug de démarque.

@Jonathan, j'ai pensé que c'était le cas.

Je ne sais pas quelle version de nHibernate vous utilisez.Je n'ai pas encore essayé la version Gold 2.0, mais vous pouvez nettoyer un peu la méthode en supprimant quelques lignes :

public static IList<T> LoadObjectListAll()
{
    ISession session = CheckForExistingSession();
    // Not sure if you can configure a session after retrieving it.  CheckForExistingSession should have this logic.
    // var cfg = new NHibernate.Cfg.Configuration().Configure();
    var criteria = session.CreateCriteria(typeof(T));
    return criteria.List<T>();
}

L'erreur la plus flagrante que je puisse constater est qu'un IList est définitivement différent d'un IList<T>.Un IList n'est pas générique (par exemple, ArrayList).

La signature de votre méthode doit donc être :

public static IList<T> LoadObjectListAll()
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top