Plan aplikacji i przebiegu pracy.

0

Witam,

W sobotę zaczynam zabierać się za projekt, który szacuje wstępnie na pół roku a po tym dalszy rozwój. Aplikację będę tworzyć sam po godzinach pracy.
Myślę, że będzie to w najlepszym razie ok. 15-20 godzin tygodniowo.

Związku z tym, że aplikacja będzie całkiem spora(w odniesieniu do moich pozostałych projektów) oraz nie będzie pisana w jeden weekend postanowiłem pierwszy raz zaplanować pracę przed jej rozpoczęciem a nie dodawania funkcjonalności na żywioł w trakcie pisania ;)

Czego potrzebuje? Metody planowania i zarządzania zadaniami.
Co znalazłem:

  1. Jira - używam w pracy ale tylko z poziomu programisty czyli przed wyjściem z pracy klikam Log Work i raz na tyg przeciągam zadanie w prawo do Done
  2. Visual Studio Online - przejrzałem na szybko, ma metodyki, podobne do jiry? Darmowe
  3. Kartka + ołówek i dużo gumek - sposób chyba najprzystępniejszy lecz nie efektywny :)

Co wy możecie polecić?

2

Jak chcesz tylko todo list to może Trello? Poza tym ja bym na twoim miejscu zaplanowal raczej architekturę aplikacji a nie zajmował się glupotami. Bo jak architektura jest dobra to można dodawać funkcjonalności na żywioł.

0

Znaczy chodzi mi o architekturę oraz funkcjonalności.

Relacje między obiektami, ich reprezentacje, formę i "sposób"(wzorce).

Nie wiem czy zwykłe TODO starczy.

Chciałbym by był podział na taski z opisem i integracją z GITem. Czyli coś jak Jira a czy taki kombajn będzie mi potrzebny okaże się w praniu bo to wszystko ładnie brzmi przed:D

Może być lokalnie ponieważ będę używać tego tylko ja na jednym sprzęcie.

0

Jedno podstawowe pytanie: czy ktoś za to zapłaci czy robisz to za free ?

0

Robię to za darmo(nie dostane za to pieniędzy) dla rodzinnej firmy.

0
Zimny Szczur napisał(a):

Co myślicie o takiej architekturze http://www.codeproject.com/Articles/70061/Architecture-Guide-ASP-NET-MVC-Framework-N-tier-En ?

Jakby się pozbyć zbędnych elementów typu repozytoria i użyć sensownych bibliotek zamiast zabawek pokroju EF i unity, to byłoby całkiem ok.

0

Co masz namyśli poprzez zbędnych? Zamierzam użyć generycznego repozytorium oraz uow by ograniczyć tworzenie provierów z tymi samymi metodami.

Sensowniejsze rzeczy? O co chodzi? Czy EF nie jest dobrym wyborem? O jakie Unity chodzi?

0
Zimny Szczur napisał(a):

Co masz namyśli poprzez zbędnych? Zamierzam użyć generycznego repozytorium oraz uow by ograniczyć tworzenie provierów z tymi samymi metodami.

Tworzenie wrapperów na coś, co już jest UoW i generycznym repozytorium, to właśnie zbędna praca.

Czy EF nie jest dobrym wyborem?

Lepszym niż pisanie SQL samemu, albo DataSety, ale jeśli chodzi o ORMy to jest słaby.

O jakie Unity chodzi?

A jakiego Unity używa autor tego tekstu? Zdaje się, że to jego kontener IoC.

0

A mógłbyś napisać w czym jest słaby EF jako ORM?

Przecież:

  1. Zabezpiecza przed różnymi atakami
  2. Upraszcza pracę z bazą danych(nie trzeba pisać ręcznie połączeń z bazą danych, zapytań i operować na DataSet.

Znasz jakieś "lepsze" ORMy, które współpracują dobrze z VS, ASP.NET MVC i darmowymi bazami jak np. SQL Server Express?

Co do IoC to w czym jest zły podany? Mógłbyś polecić lepsze?

0

Zrób sobie tablicę kanbanową. Tylko wcześniej wyodrębnij główne części architektury i historyjki, a później w miarę pracy rozbijaj te części na podtaski.

0
Zimny Szczur napisał(a):

A mógłbyś napisać w czym jest słaby EF jako ORM?

Przecież:

  1. Zabezpiecza przed różnymi atakami
  2. Upraszcza pracę z bazą danych(nie trzeba pisać ręcznie połączeń z bazą danych, zapytań i operować na DataSet.

To daje każdy ORM. A EF jest słaby. Ok, odczytasz i zapiszesz nim dane do bazy... i to wszystko. Czemu jest słaby wymieniłem tutaj: Testy jednostkowe, TDD i nazewnictwo

Nazywanie EF ORMem to tak jak nazywanie Tico samochodem, Yorka psem, a Tyskie piwem...

Znasz jakieś "lepsze" ORMy, które współpracują dobrze z VS, ASP.NET MVC i darmowymi bazami jak np. SQL Server Express?

A to EF w ogóle dobrze współpracuje z SQL Serverem? Polemizowałbym.

ORM to biblioteka dll, którą trzeba ściągnąć, podpiąć do projektu i tyle, tu nie ma żadnej magii. Dlatego też, nie ma znaczenia jakiego IDE się używa, ani to, czy pisze się aplikacje konsolową czy webową. Jedyne co ma EF, a nie mają inne ORMy to ten designer dla dzieci.

Co do IoC to w czym jest zły podany? Mógłbyś polecić lepsze?

Uważam, że konieczność ręcznej rejestracji każdej klasy do każdego interfejsu to ogromna strata czasu. Ja wolę napisać tak:

builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
                .Where(t => t.IsInNamespaceOf<ICustomersGridService>())
                .AsImplementedInterfaces();

i mieć zawsze wszystko zarejestrowane.
To akurat przykład z Autofaca, nie wiem czy inne kontenery tak potrafią.

1 użytkowników online, w tym zalogowanych: 0, gości: 1