Y a-t-il un moyen de spécifier dans une interface un type de retour connu, mais un nombre inconnu / type de paramètres.
La raison pour laquelle je demande est que j'utilise le stockage de la table Windows Azure et chaque table aura différentes clés de partition et de lignes avec différentes valeurs d'entrée. p>
Je crée une interface code> iTableOperations CODE> Le code sera quelque chose comme: p> et la table d'éléments ... pour Une autre table, les paramètres d'entrée seront différents p>
4 Réponses :
Vous pouvez définir un paramètre, ce qui serait un tableau. Ce tableau contiendrait des paires de noms / valeur et pourrait en avoir autant que nécessaire. Je pense que cela vous donnerait la flexibilité que vous recherchez. P>
Merci, mais idéalement, spécialement, lors du codage, je voudrais voir la signature, je sais donc exactement quoi passer .. j'ai pensé à objet parames code>
@Jason J'ai un code ici qui utilise le mot clé PARAMS. Je vais le poster mais ce n'est toujours pas une idée.
Je pense que "savoir exactement ce qu'il faut transmettre" pourrait-il m'exclure mutuellement avec le désir de "nombre inconnu / type de paramètres". Vous pouvez surcharger la méthode de chaque signature, mais je pense que ce serait beaucoup de surcharges. Peut-être que je ne comprends pas.
C # prend en charge plusieurs paramètres sous la forme d'un tableau à l'aide des paramètres Vous pouvez le faire: p> paramètres code>. string PartitionKey(Guid guid = default(Guid), string str = null);
Fondamentalement, la réponse courte pour exactement ce que je suis après l'avoir semblé comme on ne peut pas être fait. On dirait que l'utilisation des paramiques [] est la voie. Merci a tous. J'ai marqué cela comme la bonne réponse que Miguel était la première à y répondre, mais tout le monde a échappé à peu près à la même réponse
Ceci ne vous montrera toujours pas la liste appropriée des paramètres pour Dostuff (vous verrez simplement que parames objet [] code>) mais il est à peu près aussi flexible que vous obtiendrez. Notez que j'ai mis en place la méthode explicitement dans la classe d'implémentation afin que vous ne le voyez pas dans IntelliSense si "FOO" est déclaré comme un FOO code> plutôt que d'un ifoo code>.
Vous pouvez essayer d'avoir une interface très générique. Par exemple: alors votre implémentation pourrait être la suivante: p> public class ScheduledPostEntity : Azure.AzureTableEntity
{
private Guid _userGuid;
private DateTime _dateScheduled;
public ScheduledPostEntity()
{
// Needed for deserialisation from Azure Table Storage
}
public ScheduledPostEntity(Guid userGuid, DateTime dateScheduled)
{
_userGuid = userGuid;
_dateScheduled = dateScheduled;
}
public string PartitionKey
{
get { return _userGuid.ToString(); }
set { _userGuid = Guid.Parse(value); }
}
public string RowKey
{
get { return _dateScheduled.ReverseTicks(); }
set { _dateScheduled = value.FromReverseTicks(); }
}
// These are functions to avoid them being saved as additional properties
// in Azure Table Storage. Sometimes you can get away with them being
// read only properties, but it depends on the type.
public DateTime DateScheduled()
{
return _dateScheduled;
}
public Guid UserGuid()
{
return _userGuid;
}
}
Merci de votre réponse aussi. Une bonne idée, mais ne convient pas exactement à ce que je suis après la composition de la partition / la gaine pouvait être composée d'un certain nombre de propriétés! Je souhaite que Azure Table Stockage puisse se dépêcher et nous donner plus de contrôle quelles colonnes peuvent être indexées!
Ok, j'ai ajouté une autre idée qui pourrait vous aider.
Comment pouvez-vous utiliser cette interface?
Je veux juste m'assurer que chaque classe qui utilise cette interface a les méthodes Rowkey, PartitionKey qui renvoie une chaîne ... Il existe d'autres opérations dans les idiotières, essentiellement des opérations de CRUD.