2009-03-10 10 views
6

Dans la société pour laquelle je travaille, nous avons une application de bureau développée en .NET que nous aimons ouvrir certaines parties pour d'autres développeurs de logiciels. Je le vois comme une sorte de méthodes publiques auxquelles d'autres logiciels peuvent accéder. Existe-t-il une approche standard, des meilleures pratiques ou d'autres expériences?Comment commencer à créer une API d'application dans .NET

Je suppose que vous pourriez le faire avec des appels Win32, la programmation C/C++, etc. Mais je suis principalement un développeur .NET et j'ai quelques années d'expérience en programmation principalement en VB.NET mais aussi en C#. J'espère trouver un moyen de le faire au sein de .NET. Mais il devrait être accessible pour les logiciels développés dans d'autres langues.

Meilleures salutations/ Magnus

Répondre

6

Il y a deux façons de procéder. Le premier implique l'utilisation du modèle Plug In/Module. Start here pour cela. Un deuxième moyen consiste simplement à exposer votre logique d'API à travers des assemblages bien documentés.

La façon dont vous choisissez se résume à la façon dont vous le souhaitez. Par exemple, Adobe Photoshop utilise le modèle de plug-in dans une large mesure. MS Office utilise les deux plug-ins et fournit une interface d'objet pour travailler avec l'application.

MISE À JOUR: objets dans les assemblages .Net peuvent être exposés à être consommés par des applications externes en définissant simplement la portée des objets au public. Cela inclut les formulaires Windows, les objets métier, les énumérations, etc.

Pensez-y simplement du point de vue du développeur externe. De quelles informations auront-ils besoin pour réussir à étendre/contrôler votre produit? Quoi que ce soit, mettez-le dans le fichier d'aide.

Utilisez également les fonctionnalités d'auto-documentation de .Net. Cela inclut l'ajout de documentation XML que l'EDI sait déjà lire et afficher via intellisense. Par exemple:

/// <summary> 
/// Gets all active documents for the specified customer. 
/// </summary> 
/// <param name="customerId">The Id of the customer.</param> 
/// <returns>A list of documents for this customer.</returns> 
public static List<Document> GetDocuments(int customerId) 
{ 
    //... do something ... 
} 
+0

Merci pour la pointe sur le modèle. En ce qui concerne les "assemblées bien documentées", j'avais espéré trouver un peu plus d'informations à ce sujet, peut-être un code de référence. – Magnus

+3

Regardez Ghost doc pour un bon plugin VS pour faire votre XML Doc et regardez sandcastle pour construire une version HTML de votre doc afin que les gens qui utilisent votre API ne doivent pas patauger si source pour obtenir votre documentation. –

0

Le développement d'une API publique dépend en grande partie de la fonctionnalité de votre programme. Si vous souhaitez exposer une API accessible à d'autres langues, les services Web XML sont généralement le moyen de le faire. Toutefois, cela peut ne pas être pratique pour une application de bureau uniquement.

2

«Expose l'application via une API publique» n'est pas une définition détaillée des exigences. Avant de concevoir quoi que ce soit, obtenez des exigences détaillées.

Pour une API, je vous recommande de commencer par les exigences, puis de passer aux cas d'utilisation. Comme il s'agit d'une API, vous devriez écrire du code en utilisant l'API proposée, pour voir ce que ça fait de le programmer. Le code que vous écrivez doit couvrir les cas d'utilisation avec lesquels vous commencez. Vous pouvez même écrire ce code dans des tests unitaires, puis créer l'API via un développement et un refactoring pilotés par les tests. Mais de toute façon, comme les cas d'utilisation se concentrent sur la façon dont l'utilisateur va utiliser le logiciel, ils vous aideront à vous concentrer sur les parties du logiciel que l'utilisateur utilise directement. Un cas d'utilisation peut en utiliser un autre; mais si un utilisateur n'utilise pas directement un cas d'utilisation particulier, alors celui-ci n'a pas besoin d'être exposé publiquement.

Notez que cela m'a également aidé dans le développement de services Web.Les cas d'utilisation directement accessibles par l'utilisateur deviennent les opérations à exposer via le service. Tout cas d'utilisation que l'utilisateur n'appelle pas directement restera caché, comme implémentation.

+0

Hmm, je ne suis pas vraiment sûr de savoir comment lire cette réponse, on se sent OOT? Ma question ne concerne pas un service web ou une API publique accessible sur le web. Il s'agit d'une application de bureau locale où une entreprise partenaire aime avoir accès à certaines fonctionnalités de notre logiciel. Merci quand même. – Magnus

+0

Les mêmes principes s'appliquent. Ce qui importe, c'est que vous ayez besoin d'exposer des parties de votre application à cause de certains cas d'utilisation qui ne peuvent être accomplis sans cela. En vous concentrant sur les cas d'utilisation, vous n'exposez que ce qui est nécessaire. –

3

Créer une classe d'API qui ce que les fonctions que vous voulez que les gens d'avoir accès à et l'enregistrer pour le projet COM Interop -> propriétés -> build -> Enregistrer pour COM Interop

+0

Intéressant, se penchera sur cela. – Magnus

+0

+1 COM Interop autorise l'utilisation sur d'autres clients non .net. – eglasius

Questions connexes