[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