Questions fréquentes
Découvrez comment Lino accélère les projets .NET avec Clean Architecture, DDD, CQRS, JWT, multi-tenancy, shadow entities, RabbitMQ, Hangfire, Blazor, cache, observabilité et deploy.
Lino est une CLI permettant de générer des applications modernes dans .NET.
Il automatise l'architecture, les modules, les API, l'authentification, le frontend et l'infrastructure en mettant l'accent sur Clean Architecture, DDD et CQRS.
Lino sert à réduire le travail répétitif de démarrage et d'évolution des applications .NET.
Au lieu d'assembler manuellement la solution, les couches, les points de terminaison, l'authentification et le déploiement initial, l'équipe part d'une base toute faite et se concentre sur les règles métier.
Lino est un générateur de code pour .NET, pas un framework fermé.
Après génération, le projet appartient à l'équipe et peut être modifié sans dépendance obligatoire à l'outil.
L'objectif principal de Lino est la génération déterministe basée sur des modèles et des règles.
Cela permet de maintenir la prévisibilité, la cohérence architecturale et moins de bruit que les flux dépendants de l’IA.
Lino a été créé par Eduardo Tolino pour augmenter la productivité et standardiser l'architecture des applications modernes dans .NET.
Oui.
Les projets générés utilisent des patterns courants du logiciel d'entreprise, comme Clean Architecture, CQRS, DDD, JWT, Docker, observabilité et intégration avec des pipelines. La base générée doit encore être revue, testée et configurée pour chaque environnement de production.
La principale différence de Lino est d'accélérer la création d'applications .NET avec une base architecturale cohérente dès la première commande.
Il combine la génération de code, l'organisation modulaire, les API, le frontend, l'authentification, les événements et l'infrastructure en un seul flux.
Pour utiliser Lino, vous devez avoir installé le SDK .NET, Git, Entity Framework CLI et Docker.
dotnet tool install --global Tolitech.Lino
Après l'installation, vous pouvez vérifier la version avec lino --version.
lino project new --name MyProject
Cette commande crée la structure initiale du projet avec des couches, des modules et des configurations de base.
Lino peut générer la structure du projet, les services, les modules, les entities, les value objects, les énumérations, les commands, les queries, les APIs, les pages, les événements, les event handlers, les migrations, la configuration des secrets, les background jobs et les images Docker, selon les features sélectionnées.
Oui. Le code généré vous appartient entièrement et ne dépend pas de l'outil pour continuer à travailler.
Oui. Lino est une bonne option pour MVP lorsque vous voulez de la vitesse sans renoncer à une base propre pour évoluer plus tard.
Oui. Lino aide les projets SaaS qui ont besoin d'un backend organisé, d'authentification, d'APIs, d'un frontend web, d'une infrastructure standardisée, d'isolation de tenant, de permissions par contexte, de gestion des secrets et de rate limiting.
Oui. Lino a été conçu pour les applications métiers dans .NET qui nécessitent une séparation des couches, des modules bien définis, des API, des événements et une intégration avec une infrastructure réelle.
Les deux scénarios sont valables. Pour la plupart des produits, commencer par un monolithe modulaire est souvent plus simple et plus rentable.
Lino est logique lorsque vous devez livrer un projet .NET avec une architecture cohérente, une configuration rapide et une marge de croissance sans réécrire la base.
Si le projet est extrêmement petit, jetable ou ne nécessite pas d'architecture modulaire, le gain de Lino peut être inférieur.
Oui. Le gain réside dans l'élimination des heures ou des jours de configuration répétitive pour le backend, le frontend, l'authentification, les points de terminaison, les événements, la persistance et l'infrastructure initiale.
Les équipes .NET qui créent des produits Web, SaaS, des systèmes internes, des plates-formes B2B et des services commerciaux ont tendance à bénéficier le plus de Lino.
Lino utilise Clean Architecture, séparant le système en couches telles que domaine, application, infrastructure et présentation.
Oui. Lino encourage la modélisation basée sur le domaine avec Entities, Value Objects, Enums, Domain Events et bounded contexts.
Oui. Commands et Queries sont séparés pour faciliter l'organisation, la maintenance et l'évolutivité de l'application.
Oui. Le monolithe modulaire est l'un des scénarios les plus naturels pour Lino, surtout lorsque l'équipe souhaite de faibles coûts opérationnels avec une bonne séparation interne.
Oui. Lino peut être utilisé pour créer des monolithes modulaires, des services indépendants et des architectures basées sur des microservices.
Oui. Lino a été conçu pour renforcer la séparation des responsabilités, le couplage lâche, la modularité et l'évolution durable du code.
Entities représentent des objets avec leur propre identité au sein du domaine, tels que l'utilisateur, la commande ou le produit.
Value Objects représentent des concepts de domaine immuables qui n'ont pas leur propre identité, tels que Argent, Adresse ou Email.
Oui. Lino prend en charge Domain Events pour représenter les événements pertinents au sein du domaine et maintenir un faible couplage entre les parties du système.
Le domaine peut être divisé en modules ou bounded contexts pour refléter des domaines d'activité distincts, tels que le catalogue, les ventes, l'inventaire, l'identité ou la facturation.
Oui. Vous pouvez commencer avec quelques modules et des règles plus simples et faire évoluer la modélisation à mesure que le produit mûrit.
Oui. Lino peut générer automatiquement des points de terminaison en fonction des commandes et des requêtes de l'application.
Oui. Les API générées utilisent Minimal APIs de .NET, intégrés directement à la couche application.
Le projet généré est compatible avec la documentation API via OpenAPI et Swagger, ce qui facilite l'inspection des contrats, les tests et l'intégration entre les équipes.
Le versioning peut suivre les normes REST connues et être combiné avec une organisation par points de terminaison, contrats et builds.
Oui. L'architecture Lino vous permet d'intégrer des API externes, des webhooks, des SDK et des services tiers via la couche d'infrastructure.
Le projet généré expose les contrats d'API via OpenAPI/Swagger, et les tests pratiques des endpoints peuvent s'appuyer sur des fichiers HTTP ou des outils clients similaires selon le template et le flux choisis.
Oui. Lino prend en charge la génération d'authentification et d'autorisation pour les projets frontend et backend.
Oui. Lino prend en charge l'authentification basée sur JWT pour les API et les applications Web, en mettant l'accent sur la sécurité et l'intégration native avec ASP.NET Core.
Oui. Le modèle de sécurité de Lino inclut un contrôle d'accès plus granulaire avec des rôles, des revendications et Authorization Policies de ASP.NET Core.
Oui. Le frontend peut être intégré au flux d'authentification pour la connexion, le renouvellement des jetons et l'accès protégé aux pages et aux API.
Lino fournit des commandes de secrets, comme lino secret list, lino secret set, lino secret remove et lino secret clear, pour conserver les valeurs sensibles locales hors des fichiers versionnés. Les secrets générés peuvent aussi être modélisés comme Aspire Parameters pour les flux de publish et de deploy.
Oui. Les APIs générées peuvent démarrer avec des politiques de rate limiting pour le trafic public, les utilisateurs authentifiés, les routes avec API key et les flux de token temporaire, réduisant l'exposition avant le réglage fin de production.
Domain Events représentent les événements internes au domaine. Les Integration Events sont utilisés pour communiquer des modules, des services ou des systèmes externes de manière découplée.
Oui. Lino prend en charge les événements pour la communication entre les parties de l'application et pour l'intégration entre les services lorsque l'architecture nécessite ce modèle.
Oui. Lorsque la messagerie asynchrone est activée, Lino configure RabbitMQ comme broker afin que services et modules échangent des messages de façon découplée et résiliente.
Oui. Lino utilise MassTransit dans les scénarios de messagerie pour simplifier la publication, la consommation et l'enregistrement des événements distribués avec le modèle natif d'injection de dépendances.
Oui. Lino prend en charge les background jobs avec Hangfire pour les tâches planifiées, le traitement asynchrone, les opérations récurrentes et la visibilité opérationnelle via le dashboard Hangfire.
Utilisez les domain events pour les changements dans le domaine, les integration events pour la communication entre modules ou services, les files pour le traitement asynchrone et les background jobs pour les travaux planifiés, récurrents ou longs. Pour une publication fiable, les scénarios Lino utilisent l'Outbox Pattern.
Actuellement, Lino prend en charge les bases de données compatibles avec Entity Framework Core, telles que SQL Server et PostgreSQL.
Oui. La persistance des données est basée sur Entity Framework Core pour la modélisation, les migrations et l'évolution des bases de données tout au long du cycle de vie du projet.
Les migrations sont gérées avec Entity Framework Core et peuvent être créées via lino database migrations add, en gardant les changements de modèle explicites, versionnables et révisables avant le deploy.
Pas nécessairement. Dans les monolithes modulaires, le plus courant est une banque partagée avec une organisation claire par module.
Dans les microservices, chaque service peut avoir sa propre banque lorsque cela est logique sur le plan architectural.
Oui. Lino prend en charge l'évolution de la base de données avec des migrations et des pratiques de deploy orientées scripts, en combinant ce flux avec des ressources de build et de versioning lorsque les services sont préparés pour une release.
Oui. Lino peut générer des applications Web intégrées au backend pour accélérer la livraison de systèmes complets.
Oui. Lino peut générer des Blazor Web Apps intégrées, y compris des ressources frontend connectées aux APIs backend, la localisation et l'authentification lorsque ces features sont sélectionnées.
Oui. L'architecture Lino n'empêche pas d'utiliser React, Angular, Vue ou tout autre frontend consommateur des API du projet.
Oui. Le frontend peut fonctionner avec la connexion, le renouvellement des jetons et la consommation d'API protégées par JWT et les politiques d'autorisation.
Oui. Lino aide à structurer les pages, les composants et les fonctionnalités de manière plus standardisée, réduisant ainsi les décisions répétitives sur le frontend.
Oui. Les projets générés par Lino peuvent inclure du logging structuré, l'intégration au dashboard Aspire, des traces, des métriques et des diagnostics opérationnels pour faciliter le débogage et l'analyse en production.
Oui. Lino prend en charge les scénarios de cache avec Microsoft HybridCache et le cache distribué avec Redis lorsque cette option est activée, améliorant la cohérence entre plusieurs instances.
Oui. En standardisant la structure, les journaux, l'authentification, les API et l'infrastructure, Lino facilite l'investigation des problèmes et la maintenance opérationnelle.
La solution générée peut intégrer des health checks, des métriques, des traces, des logs et la visibilité des ressources via Aspire, selon les pratiques de l'écosystème .NET utilisées par l'architecture choisie.
Oui. Lino peut générer des images Docker de services et de web applications via le flux de build, aidant à empaqueter les artefacts pour les registries et les environnements conteneurisés.
Oui. Les projets générés peuvent être intégrés aux pipelines CI/CD pour la construction, les tests, le packaging, les migrations et le déploiement automatisé.
Le build et le versioning peuvent suivre des pratiques orientées SemVer, avec le support de Lino pour empaqueter les services et web applications sélectionnés en images Docker versionnées pour une release.
Oui. Le projet peut être publié dans le cloud, dans des environnements conteneurisés ou dans une infrastructure propre, selon la stratégie opérationnelle de l'équipe.
Oui. Lino accélère la configuration technique pour le déploiement en production avec Docker, la construction standardisée, la persistance, l'authentification et l'intégration avec les pipelines.
Lino inclut le support multi-tenant via lino feature tenant add ou lino features tenant add. La structure générée peut résoudre les tenants par domaine ou slug, appliquer les permissions par contexte et protéger les données liées à un tenant.
Les shadow entities sont des copies locales des données minimales dont un module a besoin depuis un autre contexte. La commande lino shadow new crée la structure, et l'integration event handler correspondant doit être généré séparément avec lino event-handler new.
Oui. La roadmap montre une évolution continue et indique aussi de nombreuses capacités déjà terminées, comme l'authentification JWT, Blazor Web Apps, Hangfire, RabbitMQ/MassTransit, les migrations, Docker build, HybridCache, les ressources multi-langues, smart merge, secrets et rate limiting.
La roadmap terminée inclut plusieurs capacités centrales : génération de projets .NET/Aspire, services modulaires, Minimal APIs, support de SQL Server et PostgreSQL, background jobs, messagerie, sécurité JWT, Blazor Web Apps, Docker build/versioning, user secrets, rate limiting, tenant et shadow entities.
La génération de code, les intégrations, l'expérience de développement, les flux de deploy, l'observabilité, le renforcement de la sécurité et la couverture des templates continuent d'évoluer à mesure que le produit grandit.
Vous pouvez suivre les changements sur la page de roadmap, dans la documentation et via les canaux officiels du produit. Préférez le statut de la roadmap lorsque vous devez distinguer les fonctionnalités terminées des améliorations planifiées.