Comment les gens conçoivent-ils leurs interfaces de couche de service?
Je programmment une grande application Web (en PHP) et que nous utilisons MVC et programmation de contrôleurs minces par exemple. (Code pseudo suit) p>
public function savePerson($title, $firstName, $lastName, $dateOfBirth, ... etc.. for many more) {
3 Réponses :
Mes applications MVC sont structurées comme ceci: Contrôleur -> Service -> Orm / Autre bibliothèque
Pour répondre à votre question, c'est typiquement dans votre contrôleur, vous obtiendrez des données de formulaire en tant que tableau, c'est-à-dire $ Form-> gettvalues () ou quelque chose de similaire. En termes de maintenabilité, il est préférable que vos services, à l'exception des tableaux comme arguments, de cette façon si vous ajoutez un autre champ à un formulaire, il vous suffit de mettre à jour le formulaire et le service, votre contrôleur peut rester intact et toujours fonctionner. < P> Donc, je pense aller avec votre premier exemple: En outre, vous n'auriez pas besoin d'une interface "dure" car votre bibliothèque de formulaire s'occupera de validation / filtrage / Assainissement afin que nous puissions supposer que le tableau associatif sera valide, plus la définition de la méthode sera ridiculement longue avec les paramètres nommés.
serait une façon viable de passer l'objet de formulaire alors?
Voulez-vous dire les données de la forme? Je ne suis pas à la suite de votre question Jonathan.
$ myform = nouveau mon \ forme; si ($ myform-> isvalid ($ demande-> getPost ())) {$ myservice-> dothin gs ($ myform);}
Je voudrais simplement transmettre les données du formulaire. $ Myservice-> Dothings ($ MyForm-> GetValues ()); (IIRC, appeler est valide Fournir des données filtrées lors de l'utilisation de GetValues )
Si vous allez suivre l'esprit MVC, votre L'avantage de cette étape de traduction supplémentaire est qu'il isole de votre service (modèle) de l'interface utilisateur. Si vous implémentez une UI différente, vous n'avez pas besoin de changer l'interface de service. Vous avez juste besoin d'écrire de nouveaux contrôleurs (et des vues, bien sûr).
pendant votre exemple comme Sauvegarde ne doit pas accepter l'entrée brute. Il ne doit pas être directement couplé au format des données provenant de l'interface utilisateur. Au lieu de cela, il devrait accepter l'entrée définie dans les termes de votre domaine de service, comme un objet "personne". (Cela pourrait simplement être un tableau associatif comme le lobby suggéré). Ce serait le travail de la méthode d'action du contrôleur de cartographier l'entrée brute au format requis par le service.
savePerson ($ title, $ prénom, $ nom ...) est la bonne idée, c'est généralement un mauvais signe lorsque vous avez des méthodes avec plus de 2 ou 3 arguments. Vous devriez être capable de grouper des arguments connexes dans une sorte d'objet de niveau supérieur.
Merci Dellsala (et Coplby), après avoir lu et pensé à ce sujet, préciser tous les paramètres "atomiquement" sonne comme le meilleur moyen d'aller (j'ai utilisé le projet Apache Ofbiz comme matériel de recherche ici).
Je séparerais tous les champs de saisie et fourniriez une interface "dure" dans Service E.G.
public function savePerson($title, $firstName, $lastName, $dateOfBirth) {...}