Projektowanie aplikacji z bazami danych
Prezentacje i przykłady
- Program
- Architektura
- Domain Driven Design, przykładowa architektura w .NET
- Podstawy testowania
- Podstawy SQL Server
- TSQL: podstawy, przykłady
- TSQL: programowanie, przykłady
- Kursory, przykłady
- Wyzwalacze, przykłady
- Transakcje i blokady, przykłady
- Optymalizacja
- Wprowadzenie do systemów ORM
- NHibernate, przykłady
- Podstawy LINQ, przykłady
- Walidacja, przykłady
- Prezentacja danych, przykłady
- Automapper, przykłady
- Integracja aplikacji
- RESTful services
- OData
- MicroServices
Listy zadań
| Zadanie |
Temat |
Grupa wtorkowa |
Grupa środowa |
| Lista 1 |
Wybór aplikacji, określenie wymagań |
1.3.2016 |
2.3.2016 |
| Lista 2 |
Szkielet architektury, prototypy, pierwsza przymiarka do modelu |
8.3.2016 |
9.3.2016 |
| Lista 3 |
Implementacja application services i repozytoriów w pamięci, pierwsze testy |
22.3.2016 |
23.3.2016 |
| Lista 4 |
T-SQL: podstawy |
5.4.2016 |
6.4.2016 |
| Lista 5 |
T-SQL: programowanie |
12.4.2016 |
13.4.2016 |
| Lista 6 |
Kursory i wyzwalacze |
19.4.2016 |
20.4.2016 |
| Lista 7 |
Transakcje i blokady |
26.4.2016 |
27.4.2016 |
| Lista 8 |
Dokończenie implementacji domain i application services. Utworzenie schematu bazy danych. |
10.5.2016 |
4.5.2016 |
| Lista 9 |
NHibernate |
17.5.2016 |
11.5.2016 |
| Lista 10 |
Interfejs użytkownika |
24.5.2016 |
18.5.2016 |
| Lista 11 |
Walidacja i wzorzec specyfikacji |
30.5.2016 |
1.6.2016 |
| Lista 12 |
Integracja aplikacji |
7.6.2016 (koniec semestru) |
8.6.2016 (koniec semestru) |
Roadmap
- 24.2.2016: Program, Architektura, DDD
- 2.3.2016: DDD, c.d.
- 16.3.2016: Podstawy testowania, podstawy SQL Server
- 23.3.2016: T-SQL: Podstawy
- 6.4.2016: T-SQL: Programowanie
- 13.4.2016: Kursory i wyzwalacze
- 20.4.2016: Transakcje i blokady
- 27.4.2016: Optymalizacja
- 4.5.2016: ORM, NHibernate, cz. 1
- 11.5.2016: NHibernate, cz. 2
- 18.5.2016: LINQ, Prezentacja danych w tym modele, Walidacja danych
- 1.6.2016: Automapper, Integracja aplikacji, RESTful services
Cele, zasady i wytyczne obowiązujące na pracowni
- Celem na koniec semestru jest utworzenie działającej aplikacji zgodnie z dobrymi praktykami i z zastosowaniem odpowiednich wzorców (głównie będziemy bazować na DDD). Aby osiągnąć cel, na (prawie) każde zajęcia będzie do zrobienia lista zadań mająca za zadanie przećwiczyć pewien aspekt tworzenia aplikacji, a jednocześnie dołożyć cegiełkę do docelowej aplikacji, chociaż nie wszystkie zadania będą miały za cel rozwijać aplikację. Niestety wadą tego podejścia jest to, że jak ktoś na jakimś etapie nawali, może mieć potem kłopot z robieniem kolejnych list, stąd bardzo ważna jest systematyczna praca.
- Chociaż na wykładzie będą omawiane technologie Microsoftu, jest możliwość tworzenia aplikacji w innym zestawie technologii. Trzeba jednak pamiętać, że...
- Niezbędne będzie wykazanie więcej samodzielności, ponieważ z wykładu będzie można skorzystać tylko częściowo.
- Raz wybranego zestawu zmienić już nie można (zresztą byłoby to bardzo kłopotliwe).
- Jeśli jakieś zadanie będzie blisko powiązane z jakimś aspektem technologii Microsoftu, po stronie studenta leży takie jego przeformułowanie, żeby miało zastosowania do wybranych technologii.
- Zostaną zaproponowane 2 różne aplikacje i każdy będzie realizował jedną z nich. Podczas ich realizacji oczekiwane będą pewne elementy współpracy, m.in. na pewnym etapie pojawią się zadania mające na celu integrację aplikacji. Szczegóły będą opisywane w ramach list zadań.
- Podczas rozwoju aplikacji przez cały ten semestr bardzo ważnym aspektem jest utrzymywanie dobrej jakości architektury i kodu rozwiązania (niezależnie od konieczności dodawania nowych elementów). Oznacza to, że w ramach każdej (lub co drugiej) listy zadań będzie jedno zadanie mające na celu refaktoring wersji z poprzedniego refaktoringu. Student będzie miał za zadanie przedstawić w jaki sposób poprawił rozwiązanie od ostatniego razu. To dosyć ważne - ma na celu uświadomić, że decyzje podjęte na początku tworzenia systemu, pod koniec jego tworzenia okazują się co najmniej częściowo błędne, a zwykle okazuje się to już dosyć szybko, szczególnie w przypadku nowej dziedziny, w której tworzymy system. Co więcej, ma za zadanie zmuszenie do ponownego przemyślenia całej architektury, a nie tylko skupieniu się na dodawanym elemencie.
- Na każdych zajęciach można oddawać zadania z list, które są na dany termin przewidziane.
- Zadania można oddawać tylko osobiście w trakcie trwania pracowni. Inne formy (np. wysłanie zadań poprzez e-mail) tylko po wcześniejszym uzgodnieniu z prowadzącym.
- Zebrane w trakcie semestru na pracowniach punkty się sumują i decydują o ocenie końcowej zgodnie z poniższą tabelką.
Progi punktowe
| Liczba punktów | Ocena |
|---|
| 100%-90% | 5.0 |
| 90%-80% | 4.5 |
| 80%-60% | 4.0 |
| 60%-50% | 3.5 |
| 50%-40% | 3.0 |
| 40%-0% | 2.0 |
Komplet materiałów z poprzedniego roku
