Bij het bouwen van een applicatie worden ontwikkelaars vaak geconfronteerd met de beslissing om zelf de functionaliteit te schrijven of kijken ze naar een externe component om de klus tijdig te klaren. In het laatste geval kan een goed ontworpen onderdeel de productiviteit van een ontwikkelaar enorm verbeteren. Als u componenten schrijft, hebt u de plicht ervoor te zorgen dat uw componenten goed zijn ontworpen, eenvoudig te implementeren zijn en bovendien eenvoudig te gebruiken zijn.
Zelfstudiedetails
Technologie: .NET (C #)
Moeilijkheidsgraad: gevorderd
Geschatte voltooiingstijd: 1 uur
De term "component" die in dit artikel wordt gebruikt, verwijst naar een enkel herbruikbaar programma bouwsteen. Hoewel het heel goed mogelijk is om meerdere componenten samen te groeperen om een complexe component te vormen, bespreekt dit artikel het ontwerp van eenvoudig, single-purpose componenten. Dit artikel concentreert zich op, en gebruikt, C # en .NET voor voorbeelden, maar jij kan dezelfde principes toepassen op elke taal en platform.
Er zijn drie aspecten die auteurs van componenten moeten aanspreken om bruikbaar te kunnen schrijven componenten.
Identificatie van het type component
Het ontwerpen van de API
Documentatie en verpakking
Het type van de component identificeren
Het identificeren van het type van uw component is het cruciale vertrekpunt van een schrijven een bruikbaar onderdeel. Het is onmogelijk om een schone en eenvoudige API te schrijven, en nog minder verpak het voor distributie, zonder het type adequaat te identificeren. dankbaar, deze eerste stap is eenvoudig.
De twee primaire componenttypen zijn utility-componenten om een specifieke, niet-visuele uit te voeren taak en UI-componenten (visueel) om de ervaring of het maken van de gebruiker te verbeteren ontwikkeling eenvoudiger voor de ontwikkelaar. Beschouw het volgende onderdeel als een voorbeeld:
public class HtmlRetriever public static string GetPageSource (string url) // code om HTML te krijgen van de opgegeven URL // code om de HTML terug te geven
Dit is een eenvoudig onderdeel dat alleen deze klasse HtmlRetriever bevat. Deze klas heeft een statische methode genaamd GetPageSource () die een stringparameter met bevat de URL van een pagina. Dit onderdeel bevat geen visuele elementen - het is gewoon een component die een soort functie vervult. Als zodanig kunt u dit onderdeel eenvoudig identificeren als een utility component.
Overweeg nu de volgende component, genaamd LabelTextBox, die UserControl erft en bevat markup in een ASCX-bestand:
Het feit dat deze component UserControl overerft, omvat rechtstreeks ASP.NET besturingselementen en uitgangen HTML zijn duidelijke aanwijzingen dat dit onderdeel een visuele component is. Daarom moet het worden gebruikt en beschouwd als een besturingselement, de UI-component van ASP.NET WebForms.
Zoals eerder vermeld, is identificatie de gemakkelijkste stap bij het schrijven van een bruikbare component, maar het moet worden gedaan voordat je voldoende kunt beginnen met het schrijven van code. Volg deze vuistregels bij het identificeren van het type van een component:
Als uw component het gebruik van, of gekoppeld is aan een UI-element, uw component moet zelf worden ontworpen als een gebruikersinterface-element voor het platform waarvoor u zich ontwikkelt. Als uw platform ASP.NET WebForms is, moet het onderdeel een besturingselement zijn. Als ASP.NET MVC, het zou een HTML-helper moeten zijn. Als uw platform de browser is (JavaScript), het onderdeel moet zodanig zijn ontworpen dat het zich als een HTMLElement gedraagt.
Als uw component eenvoudig met gegevens werkt en onafhankelijk is van de gebruikersinterface, is het beter diende als een utiliteitsklasse of referentietype.
Het bepalen van het type component dat u moet schrijven, bepaalt op de juiste manier hoe u werkt aanpak van de API en verpakking.
De API en waarom het belangrijk is
Een goed ontworpen API leidt natuurlijk tot productiviteit vanwege de eenvoud - ontwikkelaars besteed minder tijd aan kennis maken met de API en meer tijd aan het schrijven van code. Vanuit deze eenvoud komt ook onderhoudbaarheid, zoals het ontwerpen van uw API met eenvoud in gedachten helpt de code van de ontwikkelaar eenvoudig te houden.
Verschillende belangrijke factoren spelen een eenvoudige API, en u kunt er één bereiken door zich eraan te houden aan de volgende richtlijnen:
Volg naamgevingsconventies en algemene procedures voor uw taal en platform.
Emuleer een API van een vergelijkbaar onderdeel.
Ontwerp voor jezelf.
Ontwerp voor flexibiliteit en netheid.
Naamconventies en huisartspraktijken
Ongeacht de taal waarin u schrijft of het platform waarop u zich richt, het belangrijkste te volgen regel bij het ontwerpen van uw API is om de conventies voor naamgeving en algemeen te volgen specifieke praktijken voor uw taal en platform. Doen bevordert uniformiteit en dus eenvoud.
In het rijk van .NET zijn deze conventies gericht op twee soorten omhulsels:
Pascal zaak ñ De eerste letter van een identifier wordt met een hoofdletter geschreven. Als de identifier bestaat uit meerdere woorden, dan moet elk woord beginnen met een hoofdletter. Voorbeeld: MyClass is een eigennaam voor een klas.
Camel zaak ñ De eerste letter is een kleine letter en een volgend woord in de ID begint met een hoofdletter. Voorbeeld: myVariable.
Pascal-casus moet worden gebruikt voor alle klassenamen, opsommingen en hun waarden, gebeurtenissen, interfaces, methoden, naamruimten en eigenschappen.
Camel-case moet voor alle parameters en lokale variabelen worden gebruikt.
Emuleer een andere API
Als u helemaal opnieuw begint, is het misschien een goed idee om te zoeken naar componenten met een vergelijkbaar hulpprogramma en hun API emuleren als het maakt sinds om dit te doen. Overweeg tekstgebaseerd ASP.NET-besturingselementen als een voorbeeld. Het label en de tekstbox besturen de primaire functie is om tekst aan de gebruiker te presenteren. Als zodanig is hun standaardeigenschap de eigenschap Text. Als u een ander op tekst gebaseerd besturingselement bouwt, moet het ook een eigenschap Text implementeren om de op tekst gebaseerde inhoud van het besturingselement te verkrijgen en in te stellen.
De API voor UI-componenten is meestal veel gemakkelijker te ontwerpen en implementeren dan die van niet-visuele componenten. De UI-componenten van je doelplatform zullen meer dan waarschijnlijk een gemeenschappelijke reeks eigenschappen en methoden. Voor .NET-componenten is dit eenvoudig te bereiken door eenvoudig de System.Web.UI.Control, System.Web.UI.WebControls.WebControl te erven, of System.Web.UI.UserControl-klassen.
Het is absoluut cruciaal dat de API van uw UI-component overeenkomt met die van andere UI-componenten in je doelplatform. Het bevordert de uniformiteit en bekendheid van de ontwikkelaar - het verminderen van de hoeveelheid tijd die nodig is om een nieuwe API te leren.
Bouw een API voor jezelf
De kans is groot dat je een component bouwt voor je eigen behoeften, en je hebt later besloten om het aan de wereld vrij te geven. Na het emuleren van de API van een ander hulpprogramma of besturingselement, de volgende stap is om de eigenschappen en methoden toe te voegen die u wilt toevoegen. Jij bent tenslotte bouw het voor een specifiek doel. U bent niet alleen de eerste eigen gebruiker component, bent u ook de beste bron om het te voorzien van een API. Onthoud om houd het zo eenvoudig en logisch mogelijk. Vergeet ook niet om uw eigenschappen te verstrekken en methoden met beschrijvende en duidelijke namen.
Maak het flexibel
Zorg er bij het ontwerpen van de API voor dat deze flexibel is om met meerdere scenario's om te gaan. Gebruik de API die u zelf hebt gebouwd als basis en begin met plannen voor verschillende scenario's die andere ontwikkelaars mogelijk met uw component willen verwerken.
HtmlRetriever flexibel maken
Overweeg de klasse HtmlRetriever uit het vorige gedeelte. De GetPageSource () methode kan werken voor uw oorspronkelijke beoogde doel, maar ook uitgaan van consumenten van jouw klas wil misschien de broncode van een pagina zonder element-tags. Maak het flexibel door de methode te heractiveren in twee overbelastingen, zoals in de volgende code:
openbare klasse HtmlRetriever // de eerste "standaard" overbelasting openbare statische tekenreeks GetPageSource (tekenreeks url) retourneer GetPageSource (url, false); // de tweede overbelasting openbare statische tekenreeks GetPageSource (tekenreeks url, bool stripTags) // code om HTML-bron hier te krijgen als (stripTags) // code om tags te strippen // gegevens terugzenden
U zult nogal wat veranderingen opmerken uit deze iteratie van de klasse HtmlRetriever van wat in de vorige sectie werd gepresenteerd. Let tijdens het lezen van deze code op hoe de namen van de methoden en de namen van hun parameters zijn beschrijvend. Er is geen giswerk hier; consumenten van deze klasse weten precies wat de methode doet en hoe de parameters veranderen het gedrag eenvoudig door de naam ervan.
De eerste overbelasting fungeert als het standaardgedrag van GetPageSource () - het wordt geretourneerd de HTML-broncode van een pagina met de tags intact. De tweede overbelasting van GetPageSource () is het werkpaard van de overbelastingen van GetPageSource (). Het accepteert een URL en een Boolean waarde als zijn parameters. Het krijgt de HTML-bron en retourneert het met of zonder de elementtags, afhankelijk van welke waarde is doorgegeven aan de parameter stripTags.
Overbelasting is een fantastisch middel om flexibiliteit aan uw API toe te voegen. Het heeft ook het extra voordeel van het schoon en vrij van uw API houden van uw API.
Een API toevoegen aan LabelTextBox
Ga nu terug naar de LabelTextBox. Het erft de klasse System.Web.UI.UserControl, dus de basis van de API van de controle op zijn plaats vanuit de basisklasse. LabelTextBox is in wezen een wrapper rond een Label en een TextBox, dus sommige eigenschappen moeten worden geschreven om de eigenschappen van de onderliggende besturingselementen in te pakken. De eerste is de eigenschap Text, die wraps rond de Text-eigenschap van TextBox:
public string Text get return txtTextBox.Text; stel txtTextBox.Text = waarde in;
De beslissing om de eigenschap Text van LabelTextBox om te zetten naar die van de TextBox is een ontwerpkeuze. De TextBox ontvangt de meeste aandacht van de gebruiker; het is daarom logisch om de Text -eigenschap om de TextBox-tekst heen te laten lopen eigendom. Om de Text-eigenschap van het Label-besturingselement in te stellen, maakt u een eigenschap met de naam LabelText:
public string LabelText krijg return lblLabel.Text; set lblLabel.Text = waarde;
Deze twee eigenschappen passen bij de primaire behoefte van dit onderdeel - om waarden te verkrijgen en in te stellen. Een ontwikkelaar die deze component gebruikt, kan echter wel een TextChanged-gebeurtenis gebruiken. Dit kan eenvoudig worden gedaan met de volgende code die de TextChanged van TextBox omspant evenement:
De eerste regel van deze code geeft een EventHandler-deelnemer aan met de naam TextChanged, ontwikkelaars toestaan event handlers toe te voegen aan de TextChanged-gebeurtenis. volgende, in Page_Load () wordt de TextChanged-gebeurtenis van TextBox behandeld door txtTextBox_TextChanged () methode. Hiermee kunt u controleren of TextChanged abonnees heeft, en zo ja, uitvoeren van die event handlers.
U kunt doorgaan met het emuleren van de TextBox-eigenschappen en -methoden voor dit besturingselement. Kortheidshalve is dit zo ver als de API-emulatie in dit artikel zal gaan.
Dus de API van deze component bestaat uit vertrouwde leden, zoals de eigenschap Text en de TextChanged -gebeurtenis, evenals aangepaste eigenschappen (LabelText) die bij uw passen nodig heeft. U kunt meer aanpassingsmogelijkheden toevoegen, zoals het dynamisch aanbieden van functionaliteit voeg een validatiecontrole toe om de tekst in de TextBox te valideren. De mogelijkheden, en dus API, worden alleen beperkt door je verbeelding. Zorg er gewoon voor dat jezelf, als net als iemand anders, beschikt over de juiste hulpmiddelen om het meeste uit uw component te halen.
Laatste details: documentatie en verpakking
Hoe u uw component documenteert en verpakt, is net zo cruciaal voor de bruikbaarheid als zijn API. Al het harde werk dat je in je component stopt, is voor niets dan zijn documentatie is slecht en het is moeilijk toe te voegen aan een project. Volg de richtlijnen in dit gedeelte, en uw component kan eenvoudig aan een project worden toegevoegd.
Gebruik XML-opmerkingen
De kans is groot dat u vertrouwt op Intellisense wanneer u experimenteert met stukjes het .NET Framework waar je nog nooit mee hebt gewerkt. De meerderheid van de ontwikkelaars hetzelfde doen. Intellisense is een fantastische tool en uw component kan dit ondersteunen Intellisense als u XML-opmerkingen gebruikt en een XML-documentatiebestand genereert. De volgende code voegt een XML-opmerking toe aan de eigenschap Text van LabelTextBox:
/// /// Hiermee wordt de tekst in het tekstvak opgehaald of ingesteld. /// public string Text get return txtTextBox.Text; stel txtTextBox.Text = waarde in;
De drievoudige schuine streep is geen typfout. Typ gewoon de schuine streep drie keer boven een klasse, eigenschap of methode voegt automatisch de XML-opmerkingen voor die ID toe. De enige informatie die u moet opgeven, is wat die ID doet.
Volg deze stappen om het genereren van XML-documentbestanden in te schakelen:
Open de eigenschappenpagina's van uw project.
Klik op het tabblad Opbouwen.
Blader naar beneden en vink het selectievakje aan naast het XML-documentatiebestand.
Niet-visuele componentdistributie
Hulpprogrammaonderdelen kunnen het beste worden gedistribueerd als klassenbibliotheken. Dit geeft de ontwikkelaar een snelle en gemakkelijke manier om uw component toe te voegen aan hun project. Alles wat ze moeten doen do is een verwijzing naar het DLL-bestand toevoegen aan hun project en zij kunnen het gaan gebruiken.
Het is ook een haalbare oplossing om uw component als codebestanden vrij te geven, zolang als de code in de bestanden heeft alleen betrekking op uw component. De code inbedden een code achter, of een ander bronbestandstype, is onprofessioneel en veroorzaakt consumenten van uw component om de code te kopiëren en in afzonderlijke codebestanden te plakken.
Het beste van beide werelden: geef de DLL en de codebestanden samen vrij. Als je wilt om uw component te verkopen, kan het op sommige markten nodig zijn om de bron op te nemen code. Het bieden van een vooraf gecompileerde DLL is een bonus voor ontwikkelaars omdat ze het gewoon kunnen laat het in hun project vallen.
UI Componentdistributie
Het distribueren van UI-componenten kan een van de twee scenario's volgen. De component LabelTextBox besproken in dit artikel is een UserControl (ASCX). Dit onderdeel distribueren als een ASCX is prima. Het geeft ontwikkelaars de mogelijkheid om eenvoudig de besturing te vergroten past bij hun behoeften dankzij het opmaakgedeelte van ASCX-bestanden.
Het alternatief is om te worden afgeleid van Control of WebControl, in welk geval u dat doet om het besturingselement handmatig te coderen zonder markeringen te gebruiken. Voor eenvoudige bedieningselementen, zoals LabelTextBox, dit is niet echt een probleem. Voor complexere besturingselementen is echter meer code vereist schrijf de output HTML met Render () en RenderControl (). Deze aanpak maakt distributie veel eenvoudiger, omdat de enige toevoeging aan een project een DLL-bestand (of een codebestand) is als in tegenstelling tot de ASCX en het code-achter-bestand.
Geef nooit, nooit, uw code vrij zonder deze te verpakken.
Weinig dingen zijn frustrerender voor een ontwikkelaar dan meerdere moeten kopiëren en plakken regels code uit een ASPX-code - achter, of slechter, een ASPX-markup-bestand. Als een component auteur, het is uw verantwoordelijkheid om ervoor te zorgen dat gebruikers van uw code uw component kunnen gebruiken zo spoedig mogelijk. Alles meer dan het toevoegen van een bestand of verwijzing naar een project snel afbreuk aan de ontwikkelaar van uw component. Hou het simpel!
Sluitend
Componenten schrijven is een nobele onderneming. Je besteedt (ontelbare) uren aan het schrijven van code om het werk van een andere ontwikkelaar gemakkelijker te maken. Wees trots op het schrijven van bruikbare componenten. Hoe professioneler en bruikbaarder u ze maakt, hoe meer ontwikkelaars dit willen gebruik ze.
Verkoop ASP.NET Scripts op CodeCanyon
Wist u dat u uw ASP.NET-scripts en componenten op CodeCanyon kunt verkopen? Meld u aan voor een gratis auteursaccount en begin met verkopen!
Volg ons op Twitter of abonneer je op de Nettuts + RSS Feed voor de beste tutorials voor webontwikkeling op internet.
Share
Accentsconagua
