Par modèle commercial, ou objets métier, je veux dire des objets anciens en plats comme un "utilisateur" avec tous leurs propriétés Nom, Adresse, ...; En plus de toutes les propriétés de l'utilisateur, disons que chaque utilisateur disposerait d'un objet "Rendez-vous", chaque livre dispose d'un ensemble d'objets "TimesLot", etc. Le modèle d'entreprise a des objets avec des références entre eux, au moins c'est comme ça que je code un modèle d'entreprise en Java. Voici la question suivante:
Pour supporter mes objets métier, dans java , je voudrais
php 's Share-Nothing-Architecture me confonde pour la programmation OO appropriée:
Si j'utilise la même logique, je devrais chercher tous les objets de DB, pour chaque demande (je sais que je pouvais toujours mettre en cache, mais vous ne mettez pas en cache tout votre dB, ce n'est pas un question sur la mise en cache, mais plutôt sur la manière de la programmation en PHP et à son architecture).
Disons-le que pour une demande HTTP, j'ai juste besoin des propriétés de l'utilisateur et je n'ai pas besoin d'accéder à son livre de rendez-vous. Ce serait un pitty d'aller chercher toutes les données de la DB pour tous les objets que l'utilisateur fait référence à, car je n'ai pas besoin de ses propriétés. Cela signifie que je vais initialiser des objets PHP de mon modèle avec de nombreuses valeurs NULL (NULL en raison des objets contenus dans l'utilisateur que je ne chargerai pas) qui peut plus tard conduire à des erreurs.
Je me demandais comment les développeurs PHP professionnels utilisaient généralement leurs objets d'affaires?
(Je viens de Java)
Mise à jour: C'était un peu stupide de dire que je chargerais toute la base de données en mémoire lors de l'application init en Java. Ce que je préfère dire, c'est que, si j'ai besoin d'aller chercher un utilisateur spécifique, je pouvais simplement charger tous de ses données et qui seraient accessibles via toutes les demandes.
3 Réponses :
Dans PHP, vous ne conservez pas toutes les données de votre modèle commercial de domaine dans la mémoire. Au lieu de cela, vous ne demandez que de dB (bien que le cache, si nécessaire), les données que vous souhaitez.
La couche de modèle en PHP doit être construite à partir de plusieurs mappeurs d'objet de domaine et de données (je suppose que cette partie n'est pas si différente de Java). Si vous avez besoin de utilisateur , vous ne recherchez que cette information de la base de données / du cache. Vous aurez probablement un mappeur séparé pour traiter avec les utilisateurs.
Vous affichez les informations sur cet utilisateur et oubliez la requête. La demande suivante (quand et si elle vient) nécessitera des informations différentes. Peut-être que vous voudriez P.s. Vous pourriez avoir des avis, j'ai dit que le modèle plus tard devrait être segmenté être segmenté, mais assez souvent, les développeurs PHP créent simplement une classe unique de chaque table de DB (qui implémente ActionCord) et appelez-le "Modèle". Il s'agit d'un résultat causé par le rubis sur les rails influencent sur les développeurs-cadres PHP, qui, dans l'OMHO, est l'une des pires choses qui sont arrivées au PHP au cours des 5 dernières années. contact pour ce utilisateur ... alors vous n'avez vraiment pas besoin d'un utilisateur lui-même, seulement son user_id . Encore une fois, vous vous laissez mapper pour aller chercher des données dans l'objet de domaine responsable de la liste des contacts de gestion, et si la liste des contacts contient des instances , puis de les créer, mais laissez-la "non refusée" Etat (objet ne connaît que posséder son propre user_id). Les récupérer que si vous avez vraiment besoin de, et seules les parties que vous utiliserez sur cette "vue".
Même en Java, vous ne chargeriez pas toutes les données de la base de données en mémoire. Vous pouvez toutefois - comme vous écrivez - souvent chargez plus comparé à court scripts de transaction Vous avez normalement en PHP.
Vous devriez être "intelligents" puis pour charger uniquement les données du stockage de la persistance nécessaires pour effectuer l'action demandée. Cela nécessite que l'objet soit suffisamment "intelligent" aux données de charge paresseux probablement.
Ceci peut être obtenu avec un modèle de domaine qui sait assez à propos de lui-même et un mapper de données qui sait assez sur le stockage par exemple .
Il existe également d'autres modèles, ce qui pourrait répondre à vos besoins en fonction du type d'application, cependant un modèle de domaine avec mapper de données est assez flexible.
Un exemple de mappeur de données exemplaire dans le monde PHP est Doctrine .
Votre exemple Java implique de stocker votre contenu de votre ensemble de bases de données en mémoire. Si vous faites cela, quel est le point de la base de données? Pourquoi ne pas simplement créer tous ces objets et memdump pour la persistance.
Si j'utilise la même logique, je devrais chercher tous les objets de DB, pour chaque demande
C'est simplement une folie, vous n'avez rien à chercher, vous créez de nouvelles instances lorsque vous en avez besoin et détruisez-les lorsque vous n'en avez plus besoin.
Disons-le pour une requête HTTP, j'ai juste besoin des propriétés de l'utilisateur et je n'ai pas besoin d'accéder à son livre de rendez-vous.
C'est facile, redessinez votre utilisateur. Votre utilisateur a besoin de ses propriétés et d'une propriété appelée Nommenmentbook qui est simplement un tableau d'identifiants de livres de rendez-vous.
Si vous avez besoin de ces rendez-vous, vous pouvez les récupérer de la base de données ultérieurement.
Cela signifie que je vais initialiser des objets PHP de mon modèle avec beaucoup de valeurs NULL (NULL en raison des objets contenus dans l'utilisateur que je ne chargerai pas) qui peut plus tard conduire à des erreurs.
Pas vraiment, si c'est le cas, votre objet utilisateur est trop gros. Rendez-le plus petit, vous devez charger l'ensemble de l'utilisateur. Sauf bien sûr, l'utilisateur doit être suffisamment petit pour que vous puissiez la charge.
Si vous ne voulez pas que vous puissiez toujours créer une classe d'userProperties et que chaque utilisateur en a un. Lorsque vous chargez l'utilisateur, vous chargez les propriétés, mais vous avez également une option pour créer les propriétés séparément.
Il me semble que l'OP est plus familier avec Demande de bureau Développement. Devers de bureau _CAN _ Chargez de gros morceaux d'informations dans la mémoire et gardez-les simplement.