[TYPO3-mvc] domain modelling for extensibility
Christian Kartnig
office at hahnepeter.de
Mon Mar 31 14:36:11 CEST 2014
Hi Chris,
thanks for your helpful hints!
> * if your models have great similarity you might, extend the models
from an base-class.
Does this make it easier handling new models? Is there a kind of
extension also on the template/partial side?
> * is it likely, that you might want collections/querys of all your
12 business processes. And its therefore desirable to keep them in one
Table/Model. Or is it better to spread the data over different tables as
there are different concerns.
I definitely need queries across all 12 request forms (e.g. a filterable
list containing all 12 request forms).
Is one Table/Model my only option in this case?
If I go for one Table/Model, do I have to have one huge fluid template
full of conditions? Or is there some cleaner alternative?
Thanks a lot for your advice!
Christian
Am 31.03.14 12:45, schrieb Chris Wolff - AERTiCKET AG:
> Hi Christian,
> Here are my ideas on how to aporach this problem:
> * extbase can use models for easy form validation. There for you might want a model for every form. As validation rules might not be the same.
>
> * forms might not represent domain Models 1:1 it might be that you have one form but it does not represent one Domain model as you might generate 2 or more models out of the data (depending on the relationship).
> e.g if register a user you might ask for a address but this might easily an different record if you domain allows for multiple addresses for a user.
> Therefore you might end up with a "form-model" used for collection of data and input validation and mapping process where you generate the final models out of the input data.
>
> * if your models have great similarity you might, extend the models from an base-class.
>
> * is it likely, that you might want collections/querys of all your 12 business processes. And its therefore desirable to keep them in one Table/Model. Or is it better to spread the data over different tables as there are different concerns.
>
> * Controllers / Templates: if you have a big-Model . You might be able to use the same business logic.
> But it might get complicated as you have to do a lot of conditions in your fluid templates...
>
> * Maybe you could create a controller for every of your 12 Processes, and distil the similarity of your business logic into an "utility class" used by every controller.
> This would result in an easy control flow. And an central place to modify the business logic.
> As well as different template path for every business process.
>
> I hope these Questions help you to find your Solution to the Problem.
>
> Regards chris
>
>
> -----Ursprüngliche Nachricht-----
> Von: typo3-project-typo3v4mvc-bounces at lists.typo3.org [mailto:typo3-project-typo3v4mvc-bounces at lists.typo3.org] Im Auftrag von Christian Kartnig
> Gesendet: Montag, 31. März 2014 09:40
> An: typo3-project-typo3v4mvc at lists.typo3.org
> Betreff: [TYPO3-mvc] domain modelling for extensibility
>
> Hi there!
>
> I have a question on how to model my domain in extbase.
>
> In my domain there are about 12 different request forms, each containing a lot of fields. Roughly 40 percent of the fields are the same in every request form (but not easy to semantically extract).
> The business logic in the controller is nearly identical for each request form.
>
> How should I design the model so that I can
> - list (and filter) all request forms together, regardless of their type
> - easily add new fields in any of the request forms
> - easily add totally new request forms (copy & paste, reuse
> templates/partials?)
>
> Should I use inheritance or relations or should I treat each requestform independently for best extensibility?
>
> Thanks for your hints!
>
> best Regards,
> Christian
> _______________________________________________
> TYPO3-project-typo3v4mvc mailing list
> TYPO3-project-typo3v4mvc at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc
>
More information about the TYPO3-project-typo3v4mvc
mailing list