Projektowanie aplikacji z bazami danych
Aktualności
Jeśli komuś język SQL nie jest znany, warto skorzystać z możliwości NHibernate'a, która umożliwia na automatyczn wygenerowanie schematu bazy danych. Przykładowy wpis:
http://stackoverflow.com/questions/9720843/creating-tables-with-nhibernate1
Po przejrzeniu bieżących rozwiązań oraz przemyśleniu kierunku dalszego rozwoju aplikacji, proponuję, aby w każdej aplikacji scalić rozwiązanie do jednego bounded contextu. Niemniej jeśli ktoś widzi sens w większej ich liczbie i czuję się na siłach obsłużyć implementację komunikacji między nimi, może oczywiśćie pozostać przy bieżącym rozwiązaniu.
Prezentacje i przykłady
- Program
- Architektura, przykładowa architektura w .NET
- Domain Driven Design
- Podstawy testowania
- Wprowadzenie do systemów ORM
- NHibernate, przykłady
- Podstawy LINQ, przykłady
- Walidacja, przykłady
- Podstawy ASP.NET MVC, przykłady
- Prezentacja danych, przykłady
- Automapper, przykłady
- Usługi sieciowe
- WCF, przykłady
- WebAPI, przykłady
- OData, przykłady
- Integracja aplikacji
- Podstawy SQL, baza danych biblioteki
- PL/SQL (fragment)
Listy zadań
| Zadanie | Temat | Grupa środowa | Grupy czwartkowe | Grupa piątkowa |
| Lista 1 | Wybór aplikacji, określenie wymagań | 11.3.2015 | 12.3.2015 | 13.3.2015 |
| Lista 2 | Utworzenie architektury | 18.3.2015 | 19.3.2015 | 20.3.2015 |
| Lista 3 | Pierwsze repozytoria. Przygotowanie prototypów | 25.3.2015 | 26.3.2015 | 27.3.2015 |
| Lista 4 | Dokończenie logiki aplikacji | 1.4.2015 | 2.4.2015 | 10.4.2015 |
| Lista 5 | Implementacje repozytorium w oparciu o NH | 8.4.2015 | 9.4.2015 | 17.4.2015 |
| Lista 6 | Dalszy rozwój repozytorium w oparciu o NH | 15.4.2015 | 16.4.2015 | 24.4.2015 |
| Lista 7 | Dodanie walidacji do obiektów biznesowych | 22.4.2015 | 23.4.2015 | 8.5.2015 |
| Lista 8 | Utworzenie aplikacji interfejsu użytkownika | 13.5.2015 | 6.5.2015 | 11.5.2015 |
| Lista 9 | Implementacja integracji pomiędzy aplikacjami | 20.5.2015 | 14.5.2015 | 15.5.2015 |
| Lista 10 | Podstawy SQL w oparciu o przykładową bazę dostarczaną przez Oracle. Jeśli ktoś będzie miał kłopot z wykonaniem skryptów hr-db, może utworzyć sam schemat ze skrytu hr-db-schema, a dane dodać później samodzielnie. | 3.6.2015 | 21.5.2015 | 22.5.2015 |
| Lista 11 | Podstawy PL/SQL | 3.6.2015 | Grupa PR: 28.5.2015 Grupa PL: 11.6.2015 |
29.5.2015 |
| Lista 12 | PL/SQL, Kursory | 10.6.2015 | 11.6.2015 | 12.6.2015 |
Roadmap
- 25.2.2015: Program, Architektura, DDD
- 5.3.2015: DDD, c.d.
- 12.3.2015: Podstawy testowania. Wprowadzenie do systemów ORM
- 19.3.2015: NHibernate, cz. 1
- 26.3.2015: NHibernate, cz. 2
- 2.4.2015: NHibernate, cz. 3
- 9.4.2015: LINQ, Walidacja
- 16.4.2015: ASP.NET MVC
- 23.4.2015: Prezentacja danych, automapper
- 30.4.2015: Usługi sieciowe, WCF, WebAPI
- 6.5.2015: OData, Integracja aplikacji
- 14.5.2015: Zarządzanie schematem bazy danych, podstawy SQL
- 21.5.2015: Podstawy PL/SQL
- 28.5.2015: ???
- 11.6.2015: ???
Cele, zasady i wytyczne obowiązujące na pracowni
- Celem na koniec semestru jest utworzenie działającej aplikacji zgodnie ze sztuką 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. 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 3 różne aplikacje i każdy będzie realizował jedną z nich. Podczas realizacji będą pewne elementy współpracy, m.in. na pewnym etapie pojawią się zadania mające na celu integracje 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 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 |