web-dev-qa-db-fra.com

Une propriété pouvant représenter à la fois une date unique et une plage de date: comment modéliser correctement cela?

Je travaille dans un système qui peut représenter une "estimation de l'expédition" de deux manières:

  1. Une date spécifique: l'élément est garanti à expédier à cette date
  2. Un intervalle de jour: l'article sera expédié des jours "X à Y" d'aujourd'hui

Les informations sur le modèle sont sémantiquement la même chose, c'est "l'estimation de l'expédition". Lorsque je reçois les informations sur l'estimation de l'expédition du système, je peux indiquer si l'estimation est du premier formulaire ou du deuxième formulaire.

Le modèle actuel pour cela est similaire aux éléments suivants:

class EstimattedShippingDateDetails
{
    DateTime? EstimattedShippingDate {get; set;}
    Range? EstimattedShippingDayRange {get; set;}
}

Range est une classe simple pour envelopper un "début -> fin" d'entiers, un peu comme ça:

struct Range
{
    int Start {get; set}
    int End {get; set}

    public override ToString()
    {
        return String.Format("{0} - {1}", Start, End);
    }
}

Je n'aime pas cette approche, car une seule des propriétés sur le modèle d'estimation sera jamais remplie et je dois tester pour NULL sur l'un d'entre eux et supposer que l'autre a les données.

Chacune des propriétés est affichée différemment à l'utilisateur, mais sur le même endroit de l'interface utilisateur, à l'aide d'une touche MVC personnalisée, où la logique de commutation actuelle réside:

@Model EstimattedShippingDateDetails

@if (Model.EstimattedShippingDate.HasValue)
{
    Html.DisplayFor(m => Model.EstimattedShippingDate)
}
else
{
    Html.DisplayFor(m => Model.EstimattedShippingDayRange)
}

Comment pourrais-je modéliser cela pour le rendre plus représentatif de l'exigence réelle tout en conservant la logique d'affichage simple dans une application MVC?

J'ai pensé à utiliser une interface et deux implémentations, une pour chaque "type" d'estimation, mais je ne peux pas sembler envelopper ma tête autour d'une interface commune pour les deux. Si je crée une interface sans membres, je ne peux pas accéder aux données de manière unifiée et c'est un mauvais design IMHO. Je voulais aussi garder le point de vue aussi simple que possible. J'aurais un code "correct par construction" avec cette approche, car il n'y aurait plus besoin d'être des nullables: chaque implémentation aurait une propriété non nullable, soit un DateTime ou un Range.

J'ai également considéré seulement en utilisant un seul Range et lorsque la situation n ° 1 se produit, utilisez simplement le même DateTime pour les deux Start et End, mais cela ajouterait Complications sur la manière d'émettre les valeurs à l'interface utilisateur, car je devais alors détecter s'il s'agit d'une statique ou d'un intervalle en comparant les valeurs et en format correctement la plage à afficher comme une date unique ou un intervalle formaté.

Il semble que ce dont j'ai besoin est un concept similaire aux syndicats de type type: essentiellement une propriété pouvant être n'importe laquelle des deux types. Aucune telle chose n'existe de manière native dans C # bien sûr (seulement dynamic serait proche de cela).

c#design-patternsinheritanceasp.net-mvc
8
julealgon

Utilisez une plage de dates (c'est-à-dire deux dates) pour toutes les estimations d'expédition.

Pour une seule date, faites x et y égaux.

17
Robert Harvey

Vous avez fondamentalement 2 options:

  • 2 dates. Si l'objet représente une seule date, définissez-les à la fois sur la même valeur ou définissez le 2ème sur une valeur null.

  • 1 date et délai. La date représente le début et le tispan montre à quel point la gamme peut être dans l'avenir. Définissez la plage sur 0 pour une seule date.

Pour l'expédition, j'aurais une date d'heure plutôt qu'une date, car vous voulez sans doute modeler la livraison matin/soir. Laquelle des 2 options dépend mieux de savoir comment vous aimez calculer l'écran. Si vous affichez "entre x et y", la première option peut être plus facile à utiliser, si vous montrez "jusqu'à x jours de y", ce dernier est plus facile à utiliser.

Si vous n'aimez pas les valeurs nulles, cette dernière option est meilleure, car le calcul de la date d'origine plus la période peut être effectuée, que l'échantillon a une valeur ou est défini sur 0. Vous obtiendrez toujours un résultat correct sans vérifier pour NULL.

0
gbjbaanb