Projektowanie aplikacji z bazami danych
Prezentacje i przykłady
- Program
- Podstawy SQL Server
- TSQL: podstawy, przykłady
- TSQL: programowanie, przykłady
- Kursory, przykłady
- Wyzwalacze, przykłady
- Transakcje i blokady, przykłady
- Optymalizacja
- Architektura
- Domain-Driven Design, przykłady
- Testowanie
- Wprowadzenie do ORM
- NHibernate, przykłady
- LINQ, przykłady
- Warstwa prezentacji, modele danych, przykłady
- Automapper, przykłady
- Integracja aplikacji
- REST
- OData
- MicroServices Architecture, prezentacja Mateusza Urbańczyka
- CQRS
Listy zadań
| Zadanie |
Temat |
Grupa poniedziałkowa |
Grupa czwartkowa |
| Lista 1 |
T-SQL: podstawy |
6.3.2017 |
9.3.2017 |
| Lista 2 |
T-SQL: programowanie |
13.3.2017 |
16.3.2017 |
| Lista 3 |
Kursory, wyzwalacze |
20.3.2017 |
23.3.2017 |
| Lista 4 |
Transakcje, blokady i optymalizacja |
3.4.2017 |
6.4.2017 |
| Lista 5 |
Przygotowanie do projektu, spisanie głównych procesów i wymagań |
10.4.2017 |
13.4.2017 |
| Lista 6 |
Prototypy, struktura projektu |
24.4.2017 |
20.4.2017 |
| Lista 7 |
Repozytoria i application services |
8.5.2017 |
27.4.2017 |
| Lista 8 |
Testowanie i schemat bazy danych |
15.5.2017 |
4.5.2017 |
| Lista 9 |
Implementacja repozytorium opartego o ORM |
19.5.2017 |
18.5.2017 |
| Lista 10 |
Interfejs użytkownika |
29.5.2017 |
1.6.2017 |
| Lista 11 |
Integracja aplikacji (lista opcjonalna) |
koniec semestru |
koniec semestru |
Roadmap
- 27.2.2017: Program, T-SQL: Podstawy
- 6.3.2017: T-SQL: Programowanie
- 13.3.2017: Kursory, wyzwalacze
- 20.3.2017: Transakcje i blokady, optymalizacja
- 27.3.2017: Architektura, Domain-Driven Design
- 3.4.2017: Domain-Driven Design c.d., Testowanie
- 10.4.2017: Wprowadzenie do ORM, NHibernate
- 24.4.2017: NHibernate c.d.
- 8.5.2017: NHibernate c.d., LINQ
- 15.5.2017: Analiza agregatów na przykładzie (warsztat)
- 19.5.2017: Warstwa prezentacji, modele danych
- 29.5.2017: Automapper, Integracja aplikacji
- 5.6.2017: REST
- 12.6.2017: OData, MicroServices
- 19.6.2017: CQRS
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
