RESTful ontwerppatroon in MVC?

Ik ontwerp een applicatie die de REST-specificatie probeert te volgen. Ik probeer erachter te komen hoe ik het het beste kan ontwerpen.

Dus laten we zeggen dat ik een POST-oproep doe, dus ik heb een "post" -methode in mijn controller en model

// in controller
function post()
{
    //call post model here
}

In mijn postverzoek moet ik de volgende controles uitvoeren:

-validate fields
-make sure item name is unique for that user
-make sure there are less than 10 items
-etc (there could be more cases)

Nu in controller post-functie zal ik een REST-bericht en statuscode retourneren op basis van wat er ook gebeurt, wat prima is, maar ik ben nieuwsgierig om te weten waar het beter is om al die cheques te behouden.

Ik kan alle cheques in het model plaatsen en vervolgens een soort array retourneren zoals:

array('text' => 'return response text/array or whatever here', 'code' => '200/400/etc')

Stuur dit dan gewoon terug in de controller, of is het beter om die controles op te splitsen in individuele functies binnen het model en vervolgens alle controles in de controller uit te voeren?

// in controller
function post()
{
    //if validation fails -> send response
    //if name is not unique -> send response
    //etc...
}

Vanuit het oogpunt van het ontwerp, als ik ooit de "post" -methode in het projectmodel van andere methoden zou willen aanroepen, zou het niet een allesomvattende functie hebben om ermee om te gaan, maar als ik het allemaal in één modelfunctie houd het geeft me niet veel herbruikbaarheid. Als ik kanten zou moeten kiezen, is de kans groot dat ik deze "controlefuncties" waarschijnlijk toch niet al te veel opnieuw zou moeten gebruiken, hoewel het ook raar lijkt om al die responsinformatie in het model te hebben in plaats van de controller.

Kan iemand me hier alstublieft wat input over geven?

0

2 antwoord

Ik zou de API scheiden van de MVC-applicatie en Apify gebruiken

1
toegevoegd

Ik zou geen post-methode in het model maken (hoewel het in de controller doen prima is) simpelweg omdat je de code/het model zo in een frame plaatst dat het niet opnieuw bruikbaar en minder leesbaar is. In plaats van de postmethode in het model zou ik bijvoorbeeld de create -methode maken.

Er is geen eenduidige manier voor gegevensvalidatie. Ik vind het leuk om validatieklassen te maken die slechts één methode valideren hebben voor verschillende gegevenstypen (bijv. Gebruikersnaamvalidatieklasse controleert of deze overeenkomt met regex en is uniek). Het is beter dan het kopiëren van de validatiecode naar elke actie (DRY). Waar noem je deze klassemethode? Het hangt er van af. Je kunt het gewoon in de actie noemen. Omdat de validatiecode binnen de validatieklasse valt, ziet het er goed uit. U kunt ook een mapper maken die het verzoek indient, bepaalt welke validaties moeten worden uitgevoerd en enz., Maar het kan overkill zijn en is moeilijk om goed te doen (onderhoudbaarheid verstandig).

Voor uitvoer opnieuw - DROOG. Het hangt af van welk MVC-raamwerk u gebruikt en misschien is hier al een goede oplossing voor. Als dat niet het geval is, kun je daar een klasse voor maken (yup, I'm DRY maniac). Je geeft responscode, array (of string) door met respons en class verpakt alles netjes in JSON, XML-formaat. Voordelen: als u het uitvoerformaat wijzigt, hoeft u slechts op één plaats te wijzigen.

Overweeg ook het patroon Remote Facade te gebruiken.

Hopelijk vond je iets nuttigs in dit bericht.

1
toegevoegd
Bedankt voor het antwoord, dit gaf me een aantal ideeën. Ik gebruik codeigniter, dus ik stopte al die gevallen gewoon in een aangepaste validatieklasse en dat loste het vrijwel op. Houdt alles droog en houdt mijn regelaars en modellen schoon.
toegevoegd de auteur Rob, de bron