I've been working (alone) on a web project for four months now.
At first, I had built this kind of lame design in which my controllers both generates part of the HTML code of the view and execute its action (saving, deleting, updating).
I seek now to rectify this situation, by sticking closer to MVC design, before getting too far on my project ending up with highly tight-coupled code which would greatly reduce its reusability.
Currently, in the easiest cases, the classes are at the bottom of class hierarchy, like the translation_manager or the backup_manager classes:
In those cases, I simply had to add another level in the hierarchy structure so I can use the code both in a web browser context and a console context.
I had this other case for user account managing when I used a delegation pattern just like this:
In that case, the interface doesn't change at all. The only things that change is the table and the account treatment (like password validation).
Now, I'm struggling quite a lot for my DataImporter class.
I'm currently importing data only from other boss' software (GEM-CAR), but there's no doubt that sooner or later my boss will ask me for other software data import.
The problem is there's quite a lot of similarities in the import so I can use abstract methods like those:
<?php
abstract class DataImporter extends DataBaseManager{
abstract protected function importCustomers(PDO &$source, PDO &$destination, $importationMode = DataImportationMode::ADD_DATA);
abstract protected function importSuppliers(PDO &$source, PDO &$destination, $importationMode = DataImportationMode::ADD_DATA);
abstract protected function importTechnicians(PDO &$source, PDO &$destination, $importationMode = DataImportationMode::ADD_DATA);
abstract protected function importVehicle(PDO &$source, PDO &$destination, $importationMode = DataImportationMode::ADD_DATA);
public function launchImport(&$errorMessage, $destinationDB, $importMode, array $importList){}
}
?>
And a lot similar functions worth sharing between all import classes, but the interface might change quite a lot since I'll have to force default values (chosen by the technical support personnel) based on the data source and sub-domain setup I'm using (by example, Prestashop for ecommerce).
I don't if know it's something that can be solved using design pattern (by example the Wrapper pattern)
or if I should do like I did for my SubdomainManager with only a common interface for copying/ Setup projects/deleting sub-domain and pushing all the children classes custom interface in a sub-view based on the instanceof the children class.
Thank you for your time, Jonathan Parent-Lévesque from Montreal
Aucun commentaire:
Enregistrer un commentaire