wiki:UseCaseImplementations

Version 12 (modified by 231067, 21 hours ago) ( diff )

--

Имплементација на случаи на употреба

На следната табела се прикажани корисничките сценарија за кои ќе го прикажам кодот во контролерите:

ID Use Case Scenario Actor
7 Пребарување низ ментори Најавен корисник
9 Автоматско совпаѓање (match) со ментор Студент
10 Контактирање на ментор Студент
11 Пишување мислење за ментор Студент
12 Прифати или одби барање за контакт Ментор
13 Прифати или одби мислење на студент Ментор

Најавен корисник

Пребарување низ ментори

Најпрво имаме преглед на ментори без применето филтрирање, каде сите ментори се прикажани во грид.

Имплементацијата на кодот е следна:

Метод IsStudent() - заштитен (protected) метод кој проверува дали моментално најавениот корисник е од тип Student.

Прво го зема ID-то на најавениот корисник преку User.Identity.GetUserId(). Потоа, преку Entity Framework ја пребарува табелата Users, но само корисници од тип Student (користејќи OfType<Student>()). Методот Any враќа true ако постои студент со истото ID, во спротивно false. Овој метод се користи за контрола на логиката во View (на пример, да се прикажат одредени функционалности само за студенти).

Метод ViewMentors(...) - ActionResult метод кој враќа View со листа на ментори и поддржува повеќе параметри за пребарување и филтрирање: име, презиме, предмет, тема и достапност.

Се креира нов ApplicationDbContext и се вчитуваат сите ментори заедно со нивните предмети (Subjects) и теми (Topics) користејќи Include. Податоците од ентитетот Mentor се мапираат во EditMentorModel (ViewModel). Потоа следуваат условни филтри:

  • Ако е внесено име, се проверува дали името или презимето на менторот го содржи внесениот текст (без разлика на големи/мали букви).
  • Ако е внесено презиме, се филтрира само по презиме.
  • Ако е внесен предмет, се проверува дали некој од предметите на менторот го содржи внесениот текст.
  • Ако е внесена тема, се проверува истото за темите.
  • Ако е внесена вредност за available, таа се парсира во bool и се филтрираат само ментори со соодветна достапност.

Во ViewBag.IsStudent се сместува резултатот од методот IsStudent() за да може View-то да знае дали корисникот е студент. Потоа, View-то се враќа со филтрираната листа на ментори.

По примена на филтрирање според предмет, ги имаме следните резултати:

Корисникот може да филтрира според повеќе критериуми одеднаш.


Студент

Автоматско совпаѓање (match) со ментор

Корисниците кои се студенти можат да направат автоматско совпаѓање со ментор според предметите и интересите кои се во нивните профили.

Имплементација:

Овој HTTP GET метод служи за пронаоѓање на ментори кои најдобро одговараат на интересите и предметите на најавениот студент.

Најпрво го зема ID-то на тековниот корисник. Се вчитува студентот од базата, заедно со неговите предмети и теми. Доколку корисникот не е студент, се враќа HttpNotFound, а оваа функционалност е сокриена за ментори во View-то.

Потоа се вчитуваат сите достапни ментори со нивните предмети и интереси. Се екстрахираат листи од имиња на предмети и теми за студентот и за секој ментор се пресметува „score“ (оценка на совпаѓање) преку методот CalculateMatchScore. Се задржуваат само менторите со score поголем од 0 и се сортираат по опаѓачки редослед.

Резултатите повторно се мапираат во EditMentorModel и се враќа View-то ViewMentors, но овојпат со листа на најдобро совпаднати ментори.

CalculateMatchScore е имплементиран под него:

Ако matchType е "subjects" или "both", се пресметува пресекот помеѓу предметите на студентот и менторот. Секој заеднички предмет носи 2 поени.

Ако matchType е "interests" или "both", се пресметува пресекот помеѓу темите на интерес. Секоја заедничка тема носи 3 поени, така што темите имаат поголем приоритет од предметите.

На крај се враќа вкупниот резултат кон FindBestMatch.

Контактирање на ментор

На профилот на секој ментор се прикажани копчиња за контакт и пишување на свое мислење или искуство со менторот. Овие се видливи само за студенти:

При притискање на копчето за контакт се отвара следниот прозорец:

Откога ќе се пополни, се испраќа кон Inbox на менторот, каде што менторот одбира дали ќе го прифати или одбие барањето за контакт.

Имплементација:

Овој HTTP POST метод овозможува студент да испрати контакт-порака до ментор. Методот е заштитен со ValidateAntiForgeryToken за спречување CSRF напади.

На почеток се проверува дали е поставено MentorId. Доколку недостасува, во ModelState се додава грешка. Ако моделот не е валиден, се враќаат грешки како JSON објект ако барањето е AJAX, или повторно се враќа partial view-то ContactForm. Потоа се зема тековниот корисник и се проверува дали е студент. Доколку корисникот не е најавен како студент, се враќа грешка или Unauthorized. Ако сè е валидно, се поставува StudentId, се додава временска ознака (Timestamp), статусот се поставува на Pending се додека не одлучи менторот дали ќе го прифати или отфрли барањето, и на крај контактот се зачувува во базата.

Во зависност од типот на барањето (AJAX или не), методот враќа JSON порака за успех или редиректира кон профилот на менторот.

Пишување мислење за ментор

При притискање на копчето за пишување на мислење се отвара следниот прозорец:

Имплементацијата е многу слична со таа за контакт, освен за полињата кои ги популнува корисникот. Нема да навлезам во детали за овој дел од кодот.


Ментор

Прифати или одби барање за контакт

Пораките за контакт и мислења стигаат до менторот во неговиот Inbox, кој е имплементиран на следниот начин:

Овој метод прикажува заедничко сандаче (inbox) за студентите и менторите и е достапен само за најавени корисници ([Authorize]).

Прво се утврдува дали тековниот корисник е ментор или студент и тие информации се запишуваат во InboxCombinedViewModel.

Ако корисникот е ментор, се вчитуваат сите контакт-барања (MentorContacts) наменети за него, и сите мислења (Opinions) кои се однесуваат на него. Двата типа на барања се мапираат во заеднички DTO (RequestItemDto), па резултатите се спојуваат во едно сандаче и се сортираат по датум.

Ако корисникот е студент, се вчитуваат сите пораки испратени до него од ментори, па пораките се сортираат по датум.

На крај се враќа View со целосниот ViewModel.

Притоа, имам и имплементација за прикажување на нотификации кон корисникот:

Овој метод враќа нотификации за тековниот корисник во JSON формат и е достапен само за најавени корисници, бидејќи е тесно поврзан со сандачето за пораки.

Привремено се исклучуваат proxy и lazy loading механизмите на Entity Framework за да се избегнат проблеми со JSON серијализација.

Ако корисникот е ментор, се вчитуваат најновите контакт барања и мислења со статус Pending, па резултатите се комбинираат и се враќаат како нотификации.

Ако корисникот е студент, се вчитуваат сите непрочитани пораки од ментори и се враќа листа со нотификации како и кај менторите.

Методот враќа и информација за улогата на корисникот и бројот на нотификации.

Следи имплементација за означување на порака како прочитана:

Овој POST метод ја пронаоѓа пораката која му припаѓа на најавениот корисник. Доколку постои и не е веќе прочитана, IsRead се поставува на true и промената се зачувува во базата. Методот враќа JSON потврда за успех.


Внатре во сандачето на менторот (и во листа под нотификации) се прикажуваат сите барања и мислења кои се однесуваат на тој ментор. При отварање на едно од барањата за контакт се отвара прозорец во кој се гледаат детали за контакт барањето и менторот може да одбере дали ќе го прифати или одби барањето.

Ако го прифати, може да испрати порака кон студентот за понатамошни информации за контакт итн.

Имплементацијата на овие функционалности е следна:

  • Овој POST метод му овозможува на ментор да прифати контакт-барање од студент.

Се вчитува контакт-барањето заедно со податоците за студентот и менторот. Ако не постои, се враќа 404. Во спротивно, статусот се менува во Accepted, промената се зачувува во базата и се враќа JSON објект со податоци за студентот и барањето.

Методот е наменет за користење преку AJAX.

  • Овој POST метод овозможува ментор да испрати директна порака до студент.

Најпрво се проверува валидноста на моделот. Ако има грешки, тие се враќаат како JSON. Потоа се проверува дали корисникот е најавен. Се креира нов објект Message со испраќач (ментор), примач (студент), наслов и содржина, временска ознака и статус дека пораката не е сеуште прочитана од страна на студентот.

Пораката се зачувува во базата и се враќа JSON порака за успех.

  • Овој POST метод се користи за одбивање на контакт-барање.

Се пронаоѓа барањето по ID, статусот се поставува на Rejected, и промената се зачувува. Методот враќа HTTP 200 статус код.

Прифати или одби мислење на студент

Attachments (29)

Note: See TracWiki for help on using the wiki.