Déterminer la responsabilité de l'enregistrement des paramètres (contrôleur, services et cartographes)

Question

EDIT:

Parce que je suis à la fin avec l'attribution de la prime initiale de 300 à @arcain Je rouvre. Et l'attribution du 150 supplémentaire à @arcain. À moins bien sûr que quelqu'un fournit même une meilleure réponse. :)

/ EDIT

Considérez la forme suivante:

language | region | active | default |
-----------------------------------------------
en       | GB     | [x]    | (*)     | [X delete]
nl       | NL     | [x]    | ( )     | [X delete]
nl       | BE     | [x]    | ( )     | [X delete]

[x] let visitors browser-settings determine the default language

[save]

Les paramètres du tableau ci-dessus seront enregistrés dans une table DB colonnes qui correspondent aux colonnes ci-dessus (à l'exception de la dernière colonne évidemment).

Tous (sauvegarde et suppression) des actions directes à un contrôleur de localisation. Le contrôleur de localisation appelle essentiellement des méthodes sur un LocalizationService, comme suit:

$localizationService->updateCollection( $_POST ) // update collection settings
// or
$localizationService->delete( $_POST ) // delete a single locale

Le LocalizationService dans ce Tournons appelle un LocaleMapperDb, quelque chose comme ceci:

foreach( $localeCollection as $locale )
{
    $localeMapperDb->update( LocaleModel $locale );
}
// or
$localeMapperDb->delete( LocaleModel $locale );

Où cependant, est la responsabilité de sauvegarder ce paramètre:

[x] let visitors browser-settings determine default language

Il sera enregistré dans une table DB appelé site_settings. J'ai pensé quelques options:

• Utilisez un SiteService / SiteSettingsService dans le LocalizationController. Mais alors, la forme complète est générée et traitée dans le LocalizationService déjà.
• Utilisez un SiteMapperDb / SiteSettingsMapperDb dans le LocalizationService et l'utiliser dans updateCollection ($ _POST)
• Utilisez un SiteMapperDb / SiteSettingsMapperDb dans le LocaleMapperDb

Les premières et dernières options ressemblent les pires options, mais je ne suis pas sûr. Que ressentez-vous est la meilleure option? Ou vous avez peut-être une autre option, je n'ai pas pensé?

Answer 1

Je pense que la projection d'objets modèle de domaine sur le modèle de vue des objets fonctionne bien dans cette situation.

Dans le cas du code ci-joint (s'il vous plaît pardonnez-moi pour l'écrire en C #, il devrait être assez portable) les objets du modèle de domaine ne sont jamais exposés (ils ne sont accessibles directement dans les objets de service.) Les services qu'exposer vue objets de modèle, comme LocalViewModel et les objets de modèle de vue sont manipulés par les contrôleurs.

Les cartes LocaleConfigController également les données renvoyées par les services dans un objet LocaleConfigViewModel, et cet objet est le seul objet qui est échangé directement avec la vue.

Donc, en résumé, la vue a un contrôleur dédié, et la vue communique avec le contrôleur par l'intermédiaire de l'objet LocaleConfigViewModel. Le contrôleur manipule l'objet LocaleConfigViewModel et appels dans les implémentations du ILocaleConfigService et ISystemConfigService. Le service des objets jamais exposer le modèle de domaine au contrôleur, et ils sont responsables des objets du modèle de vue cartographie aux objets du modèle de domaine (via un mécanisme quelconque persistance est souhaitable.)

Notez que le service de localisation est une configuration service, il serait pas mise en œuvre pour rechercher ce que les chaînes localisées correctes seraient. Je mettrais cela dans un autre service, car il pourrait être utilisé dans des endroits où vous ne voudriez pas exposer toutes les méthodes qui permettraient la modification de la configuration de localisation.

Par exemple, du côté de la gestion de l'application, vous voulez à la fois le service de configuration de localisation et chaîne localisation rendu le service (depuis le site de gestion pourrait être localisé aussi bien.) Pour un client face à face avant, vous le feriez à la place probablement veulent que la chaîne de localisation rendu service parce que les modifications de configuration du système doivent être indésirables et hors de portée de ce site.

Alors, pour répondre enfin à votre question. Contrôleur contient des références à la fois les services de configuration des paramètres régionaux et du système, et le contrôleur est dédié à la vue - il a un contrat bien défini où sont échangées que LocaleConfigViewModels

Quant à savoir où se trouve la responsabilité de l'enregistrement des paramètres du système à l'échelle, le contrôleur est chargé de déballer les paramètres du système du LocaleConfigViewModel et en les poussant dans les services appropriés (dans ce cas, l'instance ISystemConfigService) où ils seront persistaient.

class LocaleViewModel
{
  public int Id;
  public string Language;
  public string Region;
  public bool Enabled;
  public bool Deleted;
}

class LocaleConfigViewModel
{
  public bool UseVisitorBrowserLocale;
  public LocaleViewModel DefaultLocale;
  public List<LocaleViewModel> Locales; 
}

class LocaleConfigController : ILocaleConfigController
{
  ILocaleConfigService localeConfig;
  ISystemConfigService systemConfig;

  public void Save(LocaleConfigViewModel model)
  {
    foreach (var locale in model.Locales)
    {
      if (locale.Deleted)
      {
        localeConfig.DeleteLocale(locale);
        continue;
      }
      localeConfig.UpdateLocale(locale);
    }
    systemConfig.DefaultLocaleId = model.DefaultLocale.Id;
    systemConfig.UseVisitorBrowserLocale = model.UseVisitorBrowserLocale;
  }

  public LocaleConfigViewModel GetCurrentView()
  {
    var model = new LocaleConfigViewModel();
    model.Locales = localeConfig.Locales;
    model.DefaultLocale = model.Locales.FirstOrDefault(l => l.Id == systemConfig.DefaultLocaleId);
    model.UseVisitorBrowserLocale = systemConfig.UseVisitorBrowserLocale;
    return model;
  }

  // ...
}

interface ILocaleConfigController
{
  void Save(LocaleConfigViewModel model);
  LocaleConfigViewModel GetCurrentView();
  // ... 
}

interface ILocaleConfigService // services will be stateless and threadsafe
{
  void DeleteLocale(LocaleViewModel locale);
  void UpdateLocale(LocaleViewModel locale);
  List<LocaleViewModel> Locales { get; }
  // ...
}

interface ISystemConfigService // services will be stateless and threadsafe
{
  int DefaultLocaleId { get; set; }
  bool UseVisitorBrowserLocale { get; set; }
  // ...
}