Hoi, 2014-07-15 10:23 GMT+02:00 Marcel van den Elst <mar...@progressiveplanning.com>: > Models hard aan URLs koppelen koppelen lijkt mij ook een anti-pattern. > Een paar redenen waarom het een anti-pattern is (NB: dit is constructief > Martijn!) is dat je het volgende verliest:
Ja, deze discussie helpt mij om te zien wat mensen als bezwaren tegen Morepath zouden kunnen inbrengen, maar er zijn een paar features in Morepath die veel van de genoemde problemen helemaal anders kunnen oplossen -- meerdere apps bijvoorbeeld, zoals we hieronder zien. > # meerdere endpoints voor zelfde model. > > Een simpel voorbeeld daarvan is dat je een PersonModel hebt in de backend, > die ontsloten wordt via een ClientResource, UserResource en > EmployeeResource. Je kunt dit in Morepath op verschillende manieren doen: * PersonModel met client view, user view, en employee view. foo_user/client foo_user/user foo_user/employee. Dat zou mijn eerdere keuze zijn -- models zijn alleen maar een endpoint als ze een view hebben. Een van die views is de 'default view', de view als je geen extra /view_name achter de URL plaatst. * Drie apps, client, user en employee, met daarin helemaal andere routes, wat je maar wilt. Dus bijv employees/foo_user, clients/foo_user. Je kunt apps ook in andere apps mounten voor apps die context nodig hebben. * een Person model, en dan een ClientPerson, UserPerson en EmployeePerson. Dit als je erachter komt dat je APIs wezelijk anders zijn bij het gebruik van Person, en er dus op model niveau eigenlijk drie models zijn, met hele andere paden. Als dit het geval is kun je ook tests schrijven zonder over web dingen na te denken. > # wijzigen backend terwijl gepubliceerde API gelijk blijft. > > Wanneer jij zelf de enige consumer van je API bent is dit misschien minder > kritisch, maar als derden gebruik maken van je API wil jij niet dat als jij > besluit of genoodzaakt bent om de backend anders in te richten, dat alle > clients (die jij niet eens hoeft te kennen) hun API /moeten/ updaten (of dat > jij dus je backend niet kunt aanpassen). Natuurlijk is het wijzigen van de code zonder dat de API verandert een use case. Maar ik zie dat probleem helemaal niet. Je kunt met de routes gewoon andere models op dezelfde paden zetten. Je zult de views natuurlijk ook moeten aanpassen. Je *zou* kunnen beargumenteren dat je met intermediate objecten zoals resources je views helemaal kunt afschermen van wijzigingen in models, maar concreet doe je dat toch meestal niet (je hebt bijvoorbeeld queries in de views). En als je dat wilt doen kun je dat op de model laag ook doen, en dan heb je het voordeel dat je zo'n facade kan opbouwen puur op model niveau. > # versioning van de API. > ... als je backend gelijkt blijft maar je besloten hebt Dat is in Morepath goed geregeld; je mount gewoon per API versie een andere app. Die apps zijn van elkaar geisoleerd, tenzij je expliciet dingen deelt door ze van elkaar te laten inheriten, of expliciet een link maakt naar iets in een andere app (of een view hergebruikt). > En het omgekeerde geval: als je backend gelijkt blijft maar je besloten hebt > om de API te veranderen, wil je niet een tweede > backend ernaast hoeven zetten. Dan verander je toch gewoon de routes? En wat de views doen natuurlijk. Omdat Morepath automatisch links maakt werken zelfs je links nog daarna. Dit soort bezwaren weegt sterker als je aan traversal naar models doet - de structuur van de models bepaalt de structuur van de URLs. Dan zijn veel van deze dingen inderdaad lastiger. Maar routing naar models heeft hele andere eigenschappen. Groeten, Martijn _______________________________________________ Python-nl mailing list Python-nl@python.org https://mail.python.org/mailman/listinfo/python-nl
