(I would) like to learn

Az alapvetések célja, hogy egyértelmű alapokat biztosítson eldönteni, hogy hol állunk, merre megyünk, mit célzunk és mit nem a munkánkkal.

• Olyan technológiát használunk, amit jelenleg programozóként a profik használnak és még jó darabig fejlődőképes marad (dotnet core).
• Olyan eszközöket használunk, amit a profi programozók is használnak.
• Olyan feladatot választunk, amit nem kell terveznünk, már létezik és körbejárható
• A tervet úgy készítjük, hogy később továbbfejleszthető legyen

Vázlatunk célja megnevezni az egymásra épülő alkalmazásainkat és megrajzolni az összefüggéseket.

• elsődleges cél: egy webalkalmazás készítése (MVC)
• továbbfejlesztés: az adatok szolgáltatása és az üzleti logika elérése webapin keresztül (MVC)
• továbbfejlesztés: desktop alkalmazás készítése a webapira alapozva (WPF)
• mobil alkalmazás készítése a webapira alapozva (Xamarin)
• továbbfejlesztés: SPA: Single Page Application készítése a webapira alapozva (Blazor)

Készítsünk egy (továbbfejleszthető) oktató alkalmazást, ahova

• oktatók tudnak tanfolyamokat feltölteni, valamint
• hallgatók tudnak ilyen tanfolyamokat elvégezni

Ez egy jól áttekinthető, mégis kellően összetett feladat, ahol a full-stack C# fejlesztés minden részébe bepillanthatunk, immár a profi fejlesztő szemével.

Az MVC az adat (Model), a vezérlő (Controller) és a nézet (View) hármasa, induljunk ki ebből és nézzük mi lenne a legegyszerűbb?

           DB                              MVC WebApp
      +-----------------+             +--------------------------------------+
      |                 |             |                                      |
      |                 |             |                                      |
      |                 |             | +-------+  +----------+  +---------+ |
      |                 | +-------->  | |       |  |          |  |         | |
      |                 |             | | EF    |  |Controller|  | View    | |
      |                 | <--------+  | | Model |  |          |  |         | |
      |                 |             | |       |  |          |  |         | |
      |                 |             | +-------+  +----------+  +---------+ |
      |                 |             |                                      |
      +-----------------+             +--------------------------------------+

Mivel az Entity Framework gyakorlatilag "tükrözi" az adatbázist, lehetne ez az MVC modelje, és már csak a vezérlő és a nézet kell. Igen ám, de mi legyen az API-val ekkor később? Annak minimum az adatokhoz hozzá kell férnie!

       DB                            EF Model                            MVC WebApp
    +-----------------+           +----------------------+           +--------------------------------------+
    |                 |           |                      |           |                                      |
    |                 | +-------> |                      | +------>  |                                      |
    |                 |           |                      |           | +-------+  +----------+  +---------+ |
    |                 | <-------+ |                      | <------+  | |       |  |          |  |         | |
    |                 |           |                      |           | | View  |  |Controller|  | View    | |
    |                 |           |                      |           | | Model |  |          |  |         | |
    |                 |           |                      |           | |       |  |          |  |         | |
    |                 |           |                      |           | +-------+  +----------+  +---------+ |
    |                 |           |                      |           |                                      |
    +-----------------+           +----------------------+           +--------------------------------------+

Ha kiemeljük az EF modelt az alkalmazásunkból, akkor az API ugyan majd később hozzáfér az adatokhoz, de milyen áron? A webalkalmazásban lévő logikai lépéseket meg kell ismételnie, így duplán dolgozunk, vagy duplikálunk, ez ugyan nem rossz megoldás, de még nem is jó.

                                                                  Service
   DB                            Repository                                              MVC WebApp
+-----------------+           +----------------------+          +-----------+        +--------------------------------------+
|                 |           |                      |          |           |        |                                      |
|                 | +-------> | +------+             | +------> |           | <----+ |                                      |
|                 |           | |      |             |          |           |        | +-------+  +----------+  +---------+ |
|                 | <-------+ | |EF    |             | <------+ |           | +----> | |       |  |          |  |         | |
|                 |           | |      |             |          |           |        | | View  |  |Controller|  | View    | |
|                 |           | |Model |             |          |           |        | | Model |  |          |  |         | |
|                 |           | |      |             |          |           |        | |       |  |          |  |         | |
|                 |           | +------+             |          |           |        | +-------+  +----------+  +---------+ |
|                 |           |                      |          |           |        |                                      |
+-----------------+           +----------------------+          +-----------+        +--------------------------------------+

Ha az EF modell mellett kiemeljük a szervezési feladatokat (legyen mondjuk üzleti logika a neve, az olyan szakzsargon-pozitív, vagy Service), akkor már van olyan pont, ahol az API be tud kapcsolódni, és lehetőség szerint nem duplikálunk majd a megvalósításnál már eleve tervezett módon kilométernyi kódokat.

• Csatolás (Coupling): ha egy elem függ más elemektől, akkor ezek az elemek csatolásban vannak.
• gyenge (Low) ez a csatolás abban az esetben, ha a csatolásban lévő elemek esetén egy változás továbbterjedése megállítható.

Első célunk tehát: a gyenge csatolás (Low Coupling) elérése a dobozaink között.

• Kohézió (Cohesion): Egy elem felelősségeinek egymáshoz való kapcsolata.
• a kohézió gyenge (low), ha az adott elemnek túl sok egymástól független felelőssége van.
• a kohézió erős (high), ha az adott elem felelősségei erősen összefüggnek és nagyon koncentráltak.

Célunk tehát az Erős kohézió (High Cohesion) elérése a dobozokon belül.

• Költségek (vajon megéri?)
  • Függ a rendelkezésre álló erőforrás mértékétől.
  • Függ a rendelkezésre álló időtől is.
  • És leginkább az alkalmazás élettartamától függ.

• legyen ef core támogatása

  • adatbázis tervezés és telepítés

• docker container támogatás

• kezdetben sqlight, majd kibővítjük ms sql-re

• Kockázatok

  • teljesítmény
  • relációs adatbázisok

További gondolatok: műszaki adósság

• CRUD műveletek elvégzése (Create, Read, Update, Delete)

• Listázás (Szűrés, sorbarendezés és lapozás)

• offline adatokat szolgáltat Sosem nem ad vissza IQueryable példányt

• adatmodell-eket szolgáltat külön kimeneti modell osztályokat nem fog használni.

• LINQ-t csak itt használunk

• Kockázatok

• transzformáció az adatmodell és a viewmodel között (Data mapping

• Validálás a ViewModel képességeit meghaladó esetben.

• Minden, amit eddig nem említettünk

• Kockázatok

• http kérés fogadása és válasz küldése MVC keretrendszer

• felhasználó azonosítás (authentikation) ASP.NET Core Identity

• jogosultságkezelés (authorization) ASP.NET Core Identity

• bejövő adatok validálása MVC ViewModel

• Kockázatok

  • több alkalmazáson át elosztott bejelentkezés és jogosultságkezelés Identity Server

• docker containeres fejlesztési környezet
• visual studio code

Projektek:

• l2l.Data
  • l2l.Data
  • l2l.Repository
• l2l.WebUI
  • l2l.Service
  • l2l.WebUI

• ef: entity framework core code first
• code: visual studio code