ඔබේ ව්‍යාපෘති සංවිධානය කරන්නේ කෙසේද? [වසා ඇත]

ව්‍යාපෘති සංවිධානය කිරීමේ විශේෂිත ශෛලියක් ඔබට තිබේද?

උදාහරණයක් ලෙස, දැනට මම බොලිවියාවේ පාසල් කිහිපයක් සඳහා ව්‍යාපෘතියක් නිර්මාණය කරමින් සිටිමි, මම එය සංවිධානය කළේ එලෙස ය:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

ඔබේ ව්‍යාපෘතිය හරියටම සංවිධානය කරන්නේ කෙසේද? ඔබ සංවිධානය කළ හා ආඩම්බර වන දෙයකට උදාහරණයක් ඔබට තිබේද? විසඳුම් කවුළුවෙහි තිර රුවක් ඔබට බෙදා ගත හැකිද?

මගේ යෙදුමේ UI ප්‍රදේශය තුළ, විවිධ ආකෘතීන් සංවිධානය කිරීමට සහ ඒවා අයත් වන්නේ කොතැනද යන්න තීරණය කිරීමට මට ගැටලුවක් තිබේ.

සංස්කරණය කරන්න:

.UI ව්‍යාපෘතියේ විවිධ ආකාර සංවිධානය කිරීම ගැන කුමක් කිව හැකිද? විවිධ ස්වරූපයන් කාණ්ඩගත කළ යුත්තේ කොතැනින් / කෙසේද? ඒවා සියල්ලම ව්‍යාපෘතියේ මූල මට්ටමට දැමීම නරක අදහසකි.

ව්‍යාපෘතියක් සැලසුම් කිරීමේදී සහ ගෘහ නිර්මාණ ශිල්පය සැකසීමේදී මම දෙපැත්තකින් ආරම්භ කරමි. පළමුවෙන්ම මම සැලසුම් කර ඇති ව්‍යාපෘතිය දෙස බලා විසඳිය යුතු ව්‍යාපාර ගැටළු මොනවාදැයි තීරණය කරමි. මම එය භාවිතා කරන පුද්ගලයින් දෙස බලා ගොරහැඩි UI සැලසුමකින් ආරම්භ කරමි. මෙම අවස්ථාවෙහිදී මම දත්ත නොසලකා හරිමින් පරිශීලකයින් ඉල්ලන්නේ කුමක්ද සහ එය භාවිතා කරන්නේ කවුරුන්ද යන්න සොයා බලයි.

ඔවුන් ඉල්ලා සිටින දේ පිළිබඳව මට මූලික අවබෝධයක් ලැබීමෙන් පසු, මූලික දත්ත යනු කුමක්ද යන්න තීරණය කර ඒවා හසුරුවනු ඇති අතර එම දත්ත සඳහා මූලික දත්ත සමුදා සැකැස්මක් ආරම්භ කරමි. ඉන්පසු දත්ත වටා ඇති ව්‍යාපාරික නීති නිර්වචනය කිරීම සඳහා මම ප්‍රශ්න ඇසීමට පටන් ගනිමි.

දෙපැත්තෙන්ම ස්වාධීනව ආරම්භ කිරීමෙන් මට ව්‍යාපෘති දෙක එකිනෙකට සම්බන්ධ වන අයුරින් සකස් කළ හැකිය. මම සෑම විටම උත්සාහ කරන්නේ ඒවා එකට ඒකාබද්ධ කිරීමට පෙර හැකි තාක් දුරට වෙන වෙනම තබා ගැනීමටයි, නමුත් මම ඉදිරියට යන විට එක් එක් අවශ්‍යතාවයන් මතකයේ තබා ගන්න.

ගැටලුවේ එක් එක් අවසානය පිළිබඳව මට හොඳ අවබෝධයක් ලැබීමෙන් පසු, ගැටළුව විසඳීම සඳහා නිර්මාණය කරනු ලබන ව්‍යාපෘතියේ ව්‍යුහය සැකසීමට පටන් ගනිමි.

ව්‍යාපෘති විසඳුමේ මූලික පිරිසැලසුම නිර්මාණය කිරීමෙන් පසු මම ව්‍යාපෘතියේ ක්‍රියාකාරීත්වය දෙස බලා සිදුකරන වැඩ වර්ගය අනුව භාවිතා වන නාම අවකාශයන් පදනම් කර ගනිමි. මෙය ගිණුම, සාප්පු කරත්ත, සමීක්ෂණ වැනි දේවල් විය හැකිය.

මෙන්න මම සෑම විටම ආරම්භ කරන මූලික විසඳුම් පිරිසැලසුම. ව්යාපෘති වඩා හොඳින් අර්ථ දක්වා ඇති විට, එක් එක් ව්යාපෘතියේ නිශ්චිත අවශ්යතා සපුරාලීම සඳහා මම එය ශෝධනය කරමි. සමහර ප්‍රදේශ අනෙක් අය සමඟ ඒකාබද්ධ කළ හැකි අතර අවශ්‍ය පරිදි විශේෂ කිහිපයක් එකතු කරමි.

විසඳුමේ නම

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

මම කැමතියි මගේ ව්‍යාපෘති ස්ථරවලට බෙදීමට

එමගින් චක්‍රීය පරායත්තතා කළමනාකරණය කිරීම පහසුය. නිදසුනක් ලෙස, කිසිදු ව්‍යාපෘතියක් වැරදීමකින් දර්ශන ව්‍යාපෘතිය (ස්තරය) ආනයනය නොකරන බවට මට සහතික විය හැකිය. මමත් උප ස්ථර වල මගේ ස්ථර බිඳ දැමීමට නැඹුරු වෙමි. එබැවින් මගේ සියලු විසඳුම් වලට මෙවැනි ව්‍යාපෘති ලැයිස්තුවක් ඇත:

• නිෂ්පාදන
• නිෂ්පාදන
• නිෂ්පාදන
• නිෂ්පාදන
• නිෂ්පාදන.යූ.අයි
• නිෂ්පාදන වලංගුකරණය
• නිෂ්පාදන. වාර්තාව
• නිෂ්පාදන. වෙබ්

ඒවා මගේ යෙදුමේ විශාල “ගොඩනැඟිලි කොටස්” වේ. සෑම ව්‍යාපෘතියක් තුළම මම වඩාත් තාර්කිකව නාම අවකාශයන්හි සංවිධානය කරමි, නමුත් එය බොහෝ වෙනස් වේ. UI සඳහා බොහෝ ආකෘති නිර්මාණය කිරීමේදී මම අවකාශීය බෙදීමකින් සිතීමට උත්සාහ කර එක් එක් "අවකාශය" සඳහා නාම අවකාශයන් නිර්මාණය කරමි. පරිශීලක මනාපයන් පරිශීලක පාලක සහ පෝරම රාශියක් ඇති බව කියමු, මට ඔවුන් සඳහා UserPreferences නමින් නාම අවකාශයක් ඇත, සහ එසේ ය.

ව්යාපෘති සංවිධානය කිරීම

මම සාමාන්‍යයෙන් උත්සාහ කරන්නේ ඔබ පවසන පරිදි මගේ ව්‍යාපෘති නාම අවකාශයෙන් බෙදීමටයි. යෙදුමක එක් එක් ස්ථරයක් හෝ සංරචකයක් එහි ම ව්‍යාපෘතියකි. මගේ විසඳුම ව්‍යාපෘති බවට පත් කරන්නේ කෙසේදැයි මම තීරණය කරන්නේ කෙසේද යන්න පිළිබඳව අවධානය යොමු කරන විට, එම ව්‍යාපෘතිවල නැවත භාවිතා කිරීමේ හැකියාව සහ යැපීම් කෙරෙහි මම අවධානය යොමු කරමි . මගේ කණ්ඩායමේ අනෙක් සාමාජිකයින් මෙම ව්‍යාපෘතිය භාවිතා කරන්නේ කෙසේද යන්න ගැන මම සිතමි, අප විසින් නිර්මාණය කරන වෙනත් ව්‍යාපෘති නම් පද්ධතියේ යම් අංගයක් භාවිතා කිරීමෙන් ප්‍රයෝජන ගත හැකිය.

උදාහරණයක් ලෙස, සමහර විට, සම්පූර්ණ රාමු සමූහයක් (ඊමේල්, ල ging ු-සටහන් ආදිය) ඇති මෙම ව්‍යාපෘතිය තිබීම පමණක් ප්‍රමාණවත් වේ:

MyCompany.Frameworks

වෙනත් වේලාවක, රාමු කැබලිවලට කැඩීමට මට අවශ්‍ය විය හැකිය, එවිට ඒවා තනි තනිව ආනයනය කළ හැකිය:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

පෝරම සංවිධානය කිරීම

ඔබේ ව්‍යාපෘතිය පුළුල් වන විට UI ව්‍යාපෘතියක් යටතේ ආකෘති සංවිධානය කිරීම සැබවින්ම වෙනස් වේ.

• කුඩා - ඉතා කුඩා ව්‍යාපෘතියක් සඳහා සරල පෝරම ෆෝල්ඩරයක් ප්‍රමාණවත් වේ. සමහර විට ඔබට නම් අවකාශයන් හා ඒවා අවශ්‍යතාවයට වඩා සංකීර්ණ කර ගත හැකි ආකාරයටම ව්‍යුහයන් ඉක්මවා යා හැකිය.

• මධ්‍යම සිට විශාල - මෙන්න, මම සාමාන්‍යයෙන් මගේ ආකෘති ක්‍රියාකාරී ප්‍රදේශවලට බෙදීමට පටන් ගනිමි. මගේ යෙදුමේ එක් කොටසක් පරිශීලකයෙකු කළමනාකරණය කිරීම සඳහා පෝරම 3 ක් සහ පාපන්දු ක්‍රීඩා සහ ලකුණු පිළිබඳව සටහන් තබා ඇති සමහරක් තිබේ නම්, එවිට මට පෝරම> පරිශීලක ප්‍රදේශයක් සහ පෝරම> ක්‍රීඩා ප්‍රදේශයක් හෝ එවැනි දෙයක් තිබේ. එය සැබවින්ම රඳා පවතින්නේ ව්‍යාපෘතියේ ඉතිරි කොටස මතය, මා එය කෙතරම් සිහින්ව කැඩී ඇත්ද යන්න පිළිබඳව මා සතුව කොපමණ ආකෘති තිබේද යන්න.

මතක තබා ගන්න, දවස අවසානයේදී නාම අවකාශ සහ ෆෝල්ඩර ඔබට සංවිධානාත්මකව හා දේවල් වේගයෙන් සොයා ගැනීමට උපකාරී වේ.

ඇත්ත වශයෙන්ම, එය ඔබගේ කණ්ඩායම, ඔබේ ව්‍යාපෘති සහ ඔබට පහසු දේ මත රඳා පවතී. පොදුවේ ගත් කල, ඔබේ පද්ධතියේ එක් එක් ස්ථරයට / සං component ටක සඳහා වෙනම ව්‍යාපෘති කළ යුතු යැයි මම යෝජනා කරමි, නමුත් සෑම විටම ව්‍යතිරේක පවතී.

පද්ධති ගෘහ නිර්මාණ ශිල්පය පිළිබඳ මග පෙන්වීම සඳහා මයික්‍රොසොෆ්ට් හි රටා සහ පරිචයන් වෙබ් අඩවිය බලන්න.

මම .NET හි කේතය ලියන විට, අදාළ ක්‍රියාකාරිත්වයේ පොකුරු තිබීමේ පැහැදිලි ප්‍රවණතාවක් පවතී. ඒ සෑම එකක්ම එකම උප කුලක තිබිය හැකිය. ප්‍රධාන කණ්ඩායම් භෞතිකව බිඳ දැමීමට මම කැමතියි - එක් වීඑස් ව්‍යාපෘතියකට මෙයින් එකක්. එකලස් කිරීම් භාවිතා කරමින් මම තවදුරටත් තර්කානුකූලව උප බෙදමි. මෙම රටාව අනුගමනය කරමින්, මගේ වර්තමාන ව්‍යාපෘති වලින් එකක් මේ ආකාරයෙන් පෙනේ:

• Wadmt (විසඳුම)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

එය ඔබට ප්‍රයෝජනවත් වේ යැයි බලාපොරොත්තු වෙමු. වෙන්වීමේ මට්ටම මට තේරුම් ගැනීමට යම් කාලයක් ගත විය.

ඔබේ විසඳුම් සංවිධානය කිරීම සඳහා සැලැස්මක් තිබීම හොඳය, එය කිරීමට ක්‍රම කිහිපයක් තිබේ. විවිධ ව්‍යාපෘති හරහා බෙදාගෙන ඇති යම් ක්‍රියාකාරිත්වයක් අප සතුව ඇති අතර එය අපගේ පරිශීලකයින් සඳහා අනුකූලතාවයක් ද සපයයි. ව්‍යාපෘති සංවිධානය රඳා පවතින්නේ අප කරන දේ මත ය. එහි හරය අපට ඇත:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

එතැන් සිට එය සැබවින්ම සැකසුම මත රඳා පවතී. අපට ග්‍රාහක යෙදුමක් සහ වෙබ් ඉදිරිපස කෙළවරක් තිබේ නම් (පන්ති කාමරයේ හෝ වෙනත් පර්යේෂණවල භාවිත ප්‍රති results ල එකතු කිරීම සඳහා ප්‍රයෝජනවත් වේ), අපට පොදුවේ බෙදාගත් කේතයක් ඇති ව්‍යාපෘතියක් අවශ්‍ය වේ (එනම් අනුක්‍රමික දත්ත වස්තු).

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

අවශ්‍ය පරිදි වෙනත් උප ව්‍යාපෘති එකතු කළ හැකිය. මම කී පරිදි, එය සැබවින්ම ව්යාපෘතිය මත රඳා පවතී. සමහර ව්‍යාපෘති සැබවින්ම සරල වන අතර අවශ්‍ය වන්නේ මූලික අංග පමණි. අපි අත්තනෝමතික ව්‍යාපෘති වෙන්කිරීමට එරෙහිව සටන් කිරීමට උත්සාහ කරන්නෙමු, එබැවින් ස්ථරවලින් බෙදීම සැබවින්ම අර්ථවත් කරයි. ස්ථර අර්ථ දැක්වෙන්නේ ව්‍යාපෘති, විසඳුම්, හෝ ප්ලගීන / දිගු හරහා බෙදාගත යුතු දේ අනුව ය.

බොහෝ අය මෙහි ඩ්‍රයි ලෙස නොසැලකීම සිත්ගන්නා කරුණකි. සංවර්ධකයින් විසින් ඩිරෙක්ටරි ව්‍යුහයන් නිර්මාණය කිරීම මගේ ජීවිතයේ කිහිප වතාවක්ම සිදුවිය. ව්‍යාපෘතියේ නම විසඳුම් සහ ව්‍යාපෘති නාමාවලි වලින් බැහැරව තබන්න!

ඉතින් මෙන්න මගේ මාර්ගය:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

මම මගේ යෙදුම සැලසුම් කරන විට, මම ඒවා නිතරම දකින්නේ ඒවා අතර යම් පරායත්තතා සහිත මොඩියුල ලෙස ය. මගේ මතකයේ සැලසුමක් ඇති විට, එය සංවර්ධනය කිරීම සඳහා මම පහළ උපාය මාර්ගයක් භාවිතා කරමි . මම එක් එක් මොඩියුලය සංවර්ධනය කර පසුව ඒවා එකට වැඩ කරමි.

හොඳයි, එම මොඩියුල මගේ විසඳුම යටතේ ඇති ව්‍යාපෘති (සාමාන්‍යයෙන් පන්ති පුස්තකාල ). සෑම මොඩියුලයකම වෙනස් නාම අවකාශයක් සහ එහි සැලසුමක් ඇත ( පන්ති ආදිය).

එම මොඩියුලවලින් එකක් වන්නේ GUI ( චිත්‍රක පරිශීලක අතුරුමුහුණත ) ය.

එක් එක් ව්යාපෘතියේ වෙනස්කම් සොයා ගැනීමට මම සෑම විටම සංශෝධන පාලන මෙවලමක් භාවිතා කරමි . මම යෝජනා කරනවා Git . එය විවෘත මූලාශ්‍රය, බෙදා හැරීම සහ භාවිතා කිරීමට නොමිලේ.

මම නව ව්‍යාපෘතියක් ආරම්භ කරන සෑම අවස්ථාවකම එය කළ යුතු දේ පිළිබඳ පුළුල් පිරිවිතරයක් ලබා ගනිමි. මෙම ආදානය තිබීම මට සන්දර්භයක් ලබා දීමෙන් මට උපකාරී වේ, එබැවින් මම ඉදිරියට ගොස් ව්‍යාපෘති අරමුණු සාක්ෂාත් කර ගැනීම සඳහා හොඳම (හෝ වඩාත් සුදුසු) ක්‍රමය සිතමි. මෙම අවස්ථාවෙහිදී, මම සිතීමට පටන් ගන්නේ අපේක්ෂිත විසඳුම ලබා දීමට කුමන රටා රටාවන් මට උපකාර කළ හැකිද යන්නයි. ව්‍යාපෘතිය සඳහා මා අනුගමනය කරන සැලසුම් රටා සැලකිල්ලට ගනිමින් මම ව්‍යාපෘතිය සංවිධානය කිරීමට පටන් ගන්නේ මෙන්න.

උදාහරණ කිහිපයක්:

1. ව්‍යාපෘතිය යොමු කරන්නේ ආදාන දත්ත තිර සෑදීම සඳහා පමණි. බොහෝ විට මම MVC රටාවක් භාවිතා කරමි.
2. මෙම ව්‍යාපෘතිය බොහෝ වේදිකා සඳහා සහය දක්වන බර වැඩ කරන UI ලෙස භාවිතා කිරීමට යන්නේ නම්, MVVM desgin රටාවක් උපකාරී වේ.

මේ සෑම දෙයක්ම ඔබේ ව්‍යාපෘතිය නිශ්චිත ආකාරයකින් සංවිධානය කිරීමට බල කරන බව මතක තබා ගන්න.

මෙන්න ඔබ වෙනුවෙන් කියවීමක්:

.නෙට් මෝස්තර රටා .

මෝස්තර රටා .

වස්තු දිශානත නිර්මාණය .

මෙය උපකාරී වේ යැයි සිතමි.