Partager via



Juin 2019

Volume 34, numéro 6

Cet article a fait l'objet d'une traduction automatique.

[Le programmeur au travail]

Codage Naked : actions Naked

Par Ted Neward | Juin 2019

Ted NewardBienvenue, NOFers. Heure du dernier, j’ai examiné comment NakedObjects gère les collections, qui offrent la possibilité d’associer un nombre d’objets avec l’autre (msdn.com/magazine/mt833439). Comme j’ai parcouru cette pièce, cependant, j’ai présenté le concept d’une « action » dans le code sans réellement l’expliquer en détail. Actions étant le jumelage pour « données » de propriétés « code », il est judicieux d’aller actions un peu plus en détail et en particulier, notez les emplacements où les actions peuvent résider et comment ils apparaissent dans l’interface utilisateur.

Vous êtes prêt à agir naked ?

Actions

Le manuel NABI décrit une action « en tant que méthode qui est destinée à être appelée par un utilisateur. » Il est important de noter, cependant, que ces méthodes ne sont pas simplement utilisateur-élément pouvant être appelé ; le manuel se passe, la même phrase, souligner que « il peut également être appelé par programme à partir d’au sein d’une autre méthode ou un autre objet. » Actions, sont ensuite, où le comportement sur un objet est défini et NABI génère un élément de menu pour l’utilisateur d’appeler/cliquez sur pour chaque action qu’il découvre.

Une telle action facilement vient à l’esprit est l’idée d’effectuer les comportements CRUD de base sur un Talk donné (ou d’un orateur, d’ailleurs), mais rappelez-vous que NABI gère déjà en tant que partie du comportement principal de l’interface utilisateur dans sa globalité. Un élément de menu hors du menu principal vous permet de créer un nouveau conférencier, qui, n’oubliez pas, est défini sur le SpeakerRepository, comme vous l’avez vu dans le deuxième article de cette série (msdn.com/magazine/mt833268). Modification ce conférencier se produit après un conférencier est sélectionné et l’utilisateur sélectionne l’élément de menu « Modifier » qui s’affiche. En fait, la seule chose qui manque dans la liste est la possibilité de supprimer un conférencier, c’est un simple point de départ, je vais maintenant ajouter une Action qui me permet de supprimer le haut-parleur actuellement visible.

(Je sais, je sais, qui souhaite jamais supprimer un conférencier ? Nous sommes tout donc savant dont, il est difficile d’imaginer que tout le monde voudriez supprimer un conférencier à partir du système. Mais avec moi sur celui-ci, à des fins pédagogiques si rien d’autre. Imaginez qu’ils prenez la retraite. Ou quelque chose.)

Pour ajouter une nouvelle action, je dois uniquement ajouter une nouvelle méthode au type de l’orateur. Par défaut, toute méthode publique sur un objet de domaine est exposée en tant qu’action dans le menu « Actions » de l’interface utilisateur, par conséquent, ajoutant Ceci est assez simple :

public void Delete()
{
  Container.DisposeInstance(this);
}

Rappelez-vous que la propriété conteneur est une instance de la IDomainObjectContainer est injecté sur chaque intervenant après sa création ou retourné à partir de la SpeakerRepository de dépendance. Pour supprimer un objet persistant (par exemple, un conférencier qui a été ajouté avec l’action CreateNewSpeaker sur le SpeakerRepository), le conteneur doit « supprimer » de cette instance.

Toutefois, lorsque j’ajouter cela à la classe de l’orateur et l’exécuter, se produit, en particulier, après la suppression de l’orateur, j’obtiens une erreur sur un objet manquant. Le client de n est signalant qu’il a été simplement afficher l’objet de domaine, conférencier qui a été simplement supprimé — n’existe plus. Qui rend une multitude de point de vue pratique, lorsque vous y pensez, et la réponse consiste à donner à l’interface utilisateur quelque chose d’autre à afficher, telles que la liste de tous les haut-parleurs restantes dans le système, je peux obtenir assez facilement à partir du conteneur à nouveau , comme suit :

public IQueryable<Speaker> Delete()
{
  Container.DisposeInstance(this);
  return Container.Instances<Speaker>();
}

Maintenant, lorsque l’utilisateur sélectionne pour supprimer un conférencier, l’interface utilisateur les supprime, affiche le reste de la liste des intervenants et se déplace de durée de vie sur. (Adieu, conférencier doux. Nous n’oubliez pas vous nostalgie.)

Un problème qui émerge, cependant, est que certains objets de domaine ont une dépendance clair sur d’autres personnes au sein du système et arbitrairement destruction de ces objets sans réfléchir à ces associations est cahier des charges de chaos. (En fait, NABI empêchera la suppression d’un objet qui comporte des objets associés jusqu'à ce que les objets associés sont supprimés en premier.) En pratique, cela signifie que si l’orateur a des discussions créées, la suppression de l’orateur laissera ceux discussions orphelin. Dans l’idéal, vous aurait pas permis d’intervenants qui ont un ou plusieurs discussions créées pour être supprimé. Vous pouvez placer une vérification à l’intérieur de la méthode Delete et fournir un message d’erreur si l’utilisateur sélectionne et vous ne pouvez pas suivre, mais il est généralement préférable de ne pas autoriser un utilisateur à l’option de la même sélection de quelque chose qu’ils n’êtes pas autorisés à faire, dans le jargon n , vous souhaitez désactiver complètement de l’action.

Une fois encore, NABI utilise les conventions d’affectation de noms pour fournir ce genre de fonctionnalités. En fournissant une méthode qui commence par le nom « Désactiver » et se poursuit avec le nom de l’action que vous souhaitez désactiver (dans ce cas, « Delete »), vous pouvez effectuer cette vérification bien avant que l’utilisateur la sélectionne jamais :

public string DisableDelete()
{
  if (Talks.Count > 0)
  {
    return "Speakers cannot be deleted until their Talks are removed.";
  }
  return null;
}

Notez que DisableDelete une chaîne, qui sera null si l’action est correctement à exécuter, ou s’affichera à l’utilisateur. (Par défaut, l’élément de menu pour l’action sera désactivé, donc il ne sont pas sélectionnables par l’utilisateur, mais souvenez-vous que les actions peuvent être appelées par d’autres moyens.)

Que se passe-t-il si vous souhaitez masquer entièrement de l’action de l’utilisateur ? C’est une autre question, mais NABI utilise la même approche — une méthode HideDelete — pour indiquer si l’action doit être affichée. Le choix entre masqué et désactivé est évidemment une subtile et probablement un débat d’expérience utilisateur d’autres sont plus qualifiées de façon à avoir que j’ai ; Je me contenterais dire que, choisissez comme votre concepteur UX ou votre cœur permet d’accéder.

Paramètres d’action

N’oubliez pas que, dans de nombreux cas, l’action nécessitera des données supplémentaires avant que celle-ci peut être effectuée. Une action souhaiterez peut-être rechercher tous les conférenciers ayant des discussions qui contiennent un terme de recherche spécifique, comme « Blockchain » ou « IoT » (J’espère que pour les supprimer entièrement à partir du système), ce qui signifie que l’utilisateur doit disposer d’une opportunité à taper dans ce terme de recherche. Là encore, n s’engage au principe de l’interface utilisateur doit être générée à partir de la structure du code lui-même, ce qui signifie dans ce cas que l’interface utilisateur examine les paramètres de la méthode et présenter un élément d’interface utilisateur qui fournit à l’utilisateur la possibilité de placer l’entrée nécessaire dans sur place. Vous avez vu ce mécanisme au travail déjà fait, dans la mesure où la méthode FindSpeakerByLastName de la SpeakerRepository fait la même chose : accepte un paramètre de chaîne pour le nom de famille pour laquelle effectuer la recherche, qui interprète les NABI à signifie qu’il doit afficher une zone de texte après cela action est appelée.

Contributions naked

Rappelez-vous que dans l’article précédent, je l’ai mentionné que le monde des objets Naked se compose d’objets de domaine et de services, où les services sont des ensembles de comportements qui n’appartiennent pas nécessairement sur l’objet de domaine. En fait, si une méthode sur un service prend un objet de domaine en tant qu’un de ses paramètres, et ce paramètre comporte un attribut « ContributedAction », l’UI NOF prend plus de pour indiquer que cette action doit apparaître dans le menu de l’objet de domaine.

Imaginez un instant que vous souhaitez que le code pour avertir les haut-parleurs que leur discussion a été acceptée à la conférence en dehors de l’objet de l’orateur. (Cela se justifie, en fait, à partir d’un domaine de point de vue, de modélisation notifier un conférencier a vraiment rien à voir avec qui est un conférencier.) Vous créez un service, puis qui ressemble à ceci (en prenant soin de vous assurer qu’il est inscrit avec n dans la propriété de Services de la classe NakedObjectsRunSettings) :

public class NotificationService
{
  public IDomainObjectContainer Container { set; protected get; }
  public void AcceptTalk([ContributedAction] Talk talk)
  {
    Container.InformUser("Great! The Speaker will be emailed right now");
  }
}

L’implémentation de la notification, bien sûr, prendra montrant plus qu’un message à l’utilisateur, mais qui n’est pas le point essentiel : la clé ici est l’attribut ContributedAction sur le paramètre de discussion, ce qui provoque cette action s’affiche dans la liste de discussion de actions. Cela offre une grande flexibilité concernant où le code s’affiche dans le système, par rapport à où il apparaît dans l’interface utilisateur.

Notez qu’il est possible de contribuer actions à des groupes d’objets de domaine, également, à l’aide du même type de la convention, appliquer uniquement à un paramètre qui est une collection d’objets de domaine plutôt que sur un seul d'entre eux. Par exemple, si je souhaite envoyer des notifications à une collection d’orateurs, je peux faire, à partir d’une méthode donnée, comme suit :

public void NotifySpeakers([ContributedAction] IQueryable<Speaker> speakers)
{
  foreach (Speaker s in speakers)
  {
    // Send SMS or email or whatever
  }
}

Du point de vue de l’interface utilisateur, n’importe quelle collection de haut-parleurs est désormais une case à cocher apparaît devant chacun d'entre eux (autorisant l’utilisateur de sélectionner parmi les haut-parleurs apparaîtra dans la collection), et le menu « Actions » présenté dans le tableau aura l’action « Notifier les haut-parleurs » affiché. Comme avec toutes les actions, si une entrée supplémentaire à partir de l’utilisateur est requise (par exemple, le message à envoyer chaque intervenant), cela s’affiche dans le cadre de l’interface utilisateur avant l’exécution de la méthode.

Pour résumer

Actions représentent un aspect important de l’expérience Naked objets Framework, car ils sont où la grande majorité des « règles d’entreprise » de n’importe quelle application sera placé. Les services peuvent fournir des opportunités hôte logique d’entreprise, pour être sûr, mais il est à l’intérieur des actions sur un objet de domaine que les développeurs pilotée par domaine recherchera les meilleures possibilités pour fournir le code pour « faire le travail. »

bon codage !


Ted Newardest consultant de polytechnology basés à Seattle, conférencier et un mentor. Il a écrit une multitude d’articles, créés et co-écrit une dizaine d’ouvrages et participe partout dans le monde. Vous pouvez le contacter ted@tedneward.com ou lire son blog à l’adresse blogs.tedneward.com.

Merci à l'expert technique suivant d'avoir relu cet article : Richard Pawson


Discuter de cet article sur le forum MSDN Magazine