Conseil n° 3 : Séparez votre VueModèle et votre Modèle de la logique d’accès aux données
Vos VueModèles représentent l’état de l’interface utilisateur et elles doivent effectuer ce travail de manière experte.
Lire l'article
Conseil n° 2 : Les classes provenant du « Add Service Reference »
Si vous écrivez une application métier Silverlight, vous allez probablement employer Windows Communication Foundation (WCF) pour enregistrer et récupérer les données.
Lire l'article
Conseil n° 1 : Séparez impérativement le Modèle de la VueModèle.
Il existe une tendance qui vise à regrouper votre Modèle et votre VueModèle dans un même objet.
Lire l'article
6 conseils sur l’approche Modèle-Vue-VueModèle
Faites un petit tour avec l’approche VueModèle et passez vos applications au crible des tests unitaires.
Lire l'article
Mythe N° 10 : profils inactifs
Le dernier mythe dont je voudrais parler est celui de la découverte des profils inactifs. Beaucoup d'utilisateurs semblent hésiter à supprimer les profils inactifs ou même à leur donner le statut *DISABLED.
Lire l'article
IBM i, 10 mythes de sécurité courants
Débusquez ces mythes pour améliorer la sécurité. Cet article se propose de dévoiler certaines des idées fausses et des erreurs courantes en matière de sécurité IBM i.
Lire l'article
Fuite de données : Le vol de disques durs
Une autre source potentielle de fuite de données est le vol de disques durs. Cette méthode n’est pas aussi répandue que les fuites liées aux périphériques mobiles ou aux périphériques de stockage USB, mais elle existe bel et bien.
Lire l'article
Fuite de données : attention aux périphériques mobiles
Les périphériques mobiles constituent une autre source importante de fuite de données. Après tout, les utilisateurs stockent habituellement des courriers électroniques, des documents, des entrées de calendrier, des contacts et d’autres données sensibles sur leurs tablettes électroniques et leurs smartphones.
Lire l'article
Fuite de données : Les périphériques de stockage USB
Ces périphériques constituent la plus grande source de fuite de données (ou, du moins, la source qui fait l’objet de la plus grande attention).
Lire l'article
IBMi Avez-vous peur des performances du journal ?
Bien entendu, le péché le plus grave est de se tenir à l'écart sans rien faire. Si vous pensez encore, comme il y a 10 ans, que l'optimisation de la performance du journal est une tâche écrasante, il est grand temps de changer d'avis.
Lire l'article
IBMi, Laissez-vous vos récepteurs de journaux languir loin de la Terre promise ?
L'un des principaux mérites de la protection par journal, particulièrement pour les sites qui n'ont pas de logiciel HA en place, est de permettre que les transactions récentes soient reprises et réexécutées à partir d'une copie du récepteur de journaux.
Lire l'article
IBMi, Avez-vous placé la barre trop haut pour votre journal ?
Chaque système IBM i est paramétré par défaut pour le comportement de journalisation cachée, visant à protéger les grands chemins d'accès (c'est-à-dire l'objet sous-jacent qui héberge les valeurs clés pour les index SQL et pour les fichiers logiques indexés).
Lire l'article
IBMi, Sous-estimez-vous le besoin de protection de vos listes d’attentes de données ?
J'ai rencontré de nombreux administrateurs système très fiers de la fiabilité de leur plate-forme IBM i et qui la comparaient à celle de certains homologues de leur site, condamnés à travailler sur un matériel et un logiciel moins fiables.
Lire l'article
Sécurité IBMi, Êtes-vous sensible aux petites dépenses et pas aux grosses ?
Certains sites s'aperçoivent que le journal est un gros consommateur de câche d'écriture validé IOA. Dès lors, ils achètent et configurent des adaptateurs IO hébergeant une quantité respectable de câche d’écriture.
Lire l'article
IBMi 6.1, Êtes-vous indifférent aux ralentissement de la transmission ?
Une approche HA avec journalisation à distance dépend beaucoup de la livraison dans les temps des nouvelles entrées de journal à la machine cible sur laquelle elles seront reproduites.
Lire l'article
IBMi, Avez-vous foi en des idoles douteuses ?
Au début de la journalisation à distance, nous, les développeurs, avons fait confiance aveuglément à la couche TCP/IP sous-jacente de support et à ses algorithmes de vérification/détection d'erreurs : après tout, c'était le standard reconnu.
Lire l'article
IBMi Dansez-vous sur une corde raide sans filet ?
Quand la journalisation à distance est apparue, quelques releases en arrière, elle s'en tenait à une seule ligne de communication TCP/IP par journal.
Lire l'article
Envoyez-vous des entrées de journaux boursouflées vers le côté cible ?
Il y a boursouflure quand vos entrées de journaux contiennent plus d'informations que nécessaire.
Lire l'article
IBMi Êtes-vous trop descriptif ?
Peut-être que du côté source vous collectez et transportez plus d'informations descriptives (par exemple, nom du job, identité du profil utilisateur, nom du programme) par entrée de journal qu'il n'en faut au logiciel replay du côté cible pour remplir sa mission.
Lire l'article
IBMi Envoyez-vous n’importe quoi à la machine cible ?
Rien ne ralentit plus une ligne de communication ou un logiciel HA replay du côté cible que des octets d'informations dont personne n'a besoin. Pourtant c'est précisément ce que beaucoup de sites font sans le savoir.
Lire l'articleLes plus consultés sur iTPro.fr
- La difficile mise en conformité avec les réglementations pour les entreprises françaises
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
