Que sont les objets métier et qu'est-ce que la logique métier?
En lisant, je continue de voir des références à ce qu'ils appellent Business Objects. J'ai recherché sur Wikipedia et autres mais je n'arrive pas à comprendre ce qu'est un Business Object.
Existe-t-il une explication facile de ce que c'est pour quelqu'un qui ne connaît rien à l'architecture logicielle et autres?
Aussi, qu'est-ce que Business Logic?
C'est facile
Chaque entité du système, représentant l'objet du monde humain avec lequel le système est censé interagir, est un objet métier.
La logique du monde humain dans le système autour de la manipulation des objets métier est une logique métier.
Cela s'oppose à ce que les objets et la logique fassent partie des détails de l'implémentation.
Par exemple, dans le système de négociation à plusieurs niveaux, l'ordre/l'échange sera un objet commercial, mais le rythme cardiaque sera le détail de la mise en œuvre.
La logique de codage des objets de commande/échange pour la diffusion en continu sera le détail de la mise en œuvre, tandis que la logique de changement de l'état de la commande à `` terminé '' une fois que le commerce arrive est une logique métier.
Eh bien, un objet métier est généralement considéré comme une classe qui représente une entité, par exemple un livre ou un magasin. Une telle classe a certaines propriétés comme le prix, la couleur, la largeur, le nombre isbn etc. Dans Java ou .NET, elle se compose de soi-disant setters et getters, c'est-à-dire des méthodes qui définissent ou obtiennent ces propriétés.
La logique commerciale, d'autre part, est la partie d'un programme qui fonctionne avec ces propriétés, c'est-à-dire comment ce livre est-il vendu. La couche de logique métier utilise les objets métier pour accéder à la base de données.
hey dévoré, j'ai eu des problèmes avec cette terminologie quand j'ai commencé à développer aussi.
Fondamentalement, la seule raison pour laquelle le mot "entreprise" est utilisé, c'est parce que la terminologie développée dans le contexte des logiciels commerciaux. Donc, dans ce sens, on suppose que le logiciel a été construit à des fins commerciales ... par opposition à des fins artistiques, esthétiques ou créatives.
Ainsi, les objets métier sont une simple représentation de code d'objets "métier" du monde réel. Ainsi, vous pourriez avoir une classe de produits ou une classe d'employés.
La logique métier est une logique au sein de l'application qui est spécifique au "métier" pour lequel le logiciel a été conçu. Donc, des choses comme les calculs de taxes, ou comment les produits sont liés aux clients ... ce genre de chose.
Notez que l'idée d'objets métier ou de logique métier ne s'appliquerait pas au développement de jeux vidéo ou au développement artistique.
Cela ne s'appliquerait pas non plus à certains frameworks ou libraires, comme ORMS ou les bibliothèques de tests unitaires, par exemple, car ce sont des composants réutilisables qui ne sont spécifiques à aucune "entreprise".
Dans la programmation traditionnelle à 3 niveaux, vous avez trois couches ou niveaux logiques. Vous avez une couche de présentation qui est l'interface utilisateur, la couche inférieure serait la couche de base de données. La couche intermédiaire serait la couche d'objets métier. Comme indiqué ci-dessus, les objets métier doivent être résumés en ce que le site peut ne pas être du tout consacré aux affaires. Il s'agit d'une couche d'abstraction qui facilite la modification de la couche de présentation ou le passage à une autre source de données.
Si votre niveau d'interface utilisateur n'a pas ou très peu de code derrière. Cela permet aux concepteurs de travailler plus facilement avec les programmeurs. Les concepteurs peuvent changer l'aspect et la convivialité du site sans que les programmeurs n'aient à effectuer une réécriture substantielle du code qui fait fonctionner ce site. Avec la couche d'objets métier, vous effectuez la lourde liste du site. Vous effectuez des appels dans la couche de base de données sans que l'objet métier sache si votre couche de base de données est en XML ou en base de données relationnelle. Et la couche d'objet métier mettrait alors à jour une réponse à la couche d'interface utilisateur. Généralement, l'exemple utilisé concerne une transaction bancaire. Dans l'interface utilisateur, un client saisit le montant qu'il souhaite transférer de son compte d'épargne vers son compte courant.
La couche d'objet métier contiendra les règles métier de la banque. Cela signifie qu'il vérifiera le solde du compte d'épargne des utilisateurs et s'assurera que le montant à transférer ne dépasse pas le solde du compte. La couche de gestion contiendra les classes qui calculent réellement les nouveaux soldes pour le compte d'épargne et le compte courant et elle alertera la couche de base de données pour mettre à jour la base de données.
C'est l'opposé de Fun Logic.
Objet métier:
class User {
long id;
String fullNames;
int age;
}
class Book {
long id;
String bookTitle;
}
class Sales {
long id;
long userID;
long bookID;
}
Logique métier:
class BookSalesController {
private User user = new User();
private Book book = new Book();
private Sales sale = null;
public Sale sale(long saleID) {
String query = "SELECT * FROM Sales s WHERE s.id = :saleID";
....
.... execute the query
// Assuming we have our Result Set here by now
if (rs.next()) {
sale = new Sales(rs.getString("User Names"));
sale.setUserID(rs.getLong(userID));
sale.setBookID(rs.getLong(bookID));
}
return sale;
}
}
Une définition d'un objet métier est difficile à obtenir sur le moteur de recherche car elle vous dira que Business Objects est une entreprise acquise par SAP. Mais ce n'est pas ce que la plupart des gens recherchent.
Un objet métier est l'encapsulation du modèle logique métier d'un scénario métier.
Par exemple: dans le domaine des achats: il existe toute une liste d'activités à réaliser. De l'analyse des dépenses à la demande d'informations sur les produits et à la génération du contrat pour la durée négociée. Ainsi, dans ce scénario particulier, un document comme RFI (Request for information) peut être considéré comme une instance d'un objet métier RFI (il aura toute la logique liée au processus comme la validation, etc.).
L'objet métier de la série SAP est différent de l'objet métier à l'intérieur du modèle de conception Oracle'core qui interagit avec la couche de service d'application ... oui, l'objet métier fonctionne avec une entité composite, mais il a une logique métier, il peut porter l'état métier, certains sont faciles ajustez les méthodes et elles sont porteuses d'informations commerciales avec les états dynamiques échangeables et traversent les niveaux ou domaines d'application, mais lorsque dans un contexte différent, elles ont un nom spécifié détaillé différent, par exemple, nous pouvons dire que la demande de service Web est un objet métier au format xml ... ce n'est pas la même chose que l'entité de données