Category Archives: TimePlanner

Do czego służy plik Global.asax?

W aplikacji webowej ASP.NET MVC możemy znaleźć plik Global.asax zawierający klasę MvcApplication dziedziczącą po klasie HttpApplication. Postanowiłem poświęcić temu kolejny wpis, ponieważ myślę że warto opisać do czego on służy, tym bardziej że pytanie to może być także zadane na rozmowach o pracę 😉

global Plik Global.asax jest to opcjonalny plik zawierający kod, który odpowiada za reagowanie na zdarzenia zgłoszone z poziomu aplikacji i poziomu sesji takie jak start aplikacji, zakończenie sesji, itp. Plik ten jest opcjonalny, czyli nie musimy reagować na te zdarzenia, jeżeli nie chcemy.
Domyślnie plik ten zawiera następujący kod:

public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()

        {
            AreaRegistration.RegisterAllAreas();
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
        }
    }

public class MvcApplication : System.Web.HttpApplication

{

protected void Application_Start()

{

AreaRegistration.RegisterAllAreas();

FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);

RouteConfig.RegisterRoutes(RouteTable.Routes);

BundleConfig.RegisterBundles(BundleTable.Bundles);

}

Jak widać jest tutaj tylko zaimplementowane obsłużenie zdarzenia startu aplikacji, jednak nic nie stoi na przeszkodzie, aby dodać obsługę innych zdarzeń.
W tym celu wystarczy dodać odpowiednio nazwaną metodę/metody np.

        protected void Application_End()
        {
            //...
        }

        protected void Session_Start()
        {
            //...
        }

        protected void Session_End()
        {
            //...
        }

        protected void Application_BeginRequest()
        {
            //...
        }

protected void Application_End()

{

//...

}

protected void Session_Start()

{

//...

}

protected void Session_End()

{

//...

}

protected void Application_BeginRequest()

{

//...

}

To wszystko, nie musimy robić nic więcej (poza implementacją reakcji na zdarzenie). Gdy zdarzenie zostanie zgłoszone, zostanie ono odpowiednio obsłużone.
Lista zdarzeń wraz z krótkim opisem każdego z nich prezentuje się następująco:

Application_Init: pojawia się podczas inicjalizacji aplikacji albo pierwszego wywołania.
Application_Disposed: pojawia się zaraz przed końcem życia aplikacji. Idealne miejsce do zwolnienia używanych zasobów.
Application_Error: pojawia się podczas wystąpienia błędu, który nie został obsłużony w aplikacji.
Application_Start: pojawia się podczas stworzenia pierwszej instancji klasy HttpApplication. Pozwala na stworzenie obiektów dostępnych we wszystkich instancjach HttpApplication.
Application_End: pojawia się, kiedy ostatnia instancja klasy HttpApplication kończy swój cykl życia. Odpalany tylko raz.
Application_BeginRequest: pojawia się podczas odebrania żądania aplikacji. Jest to pierwsze odpalane zdarzenie.
Application_EndRequest: jest to ostatnie zdarzenie, które pojawia się podczas żądania aplikacji.
Application_PreRequestHandlerExecute: pojawia się przed wykonaniem obsługi zdarzenia strony albo web serwisu.
Application_PostRequestHandlerExecute: pojawia się na koniec wykonania obsługi zdarzenia.
Applcation_PreSendRequestHeaders: pojawia się przed wysłaniem nagłówków HTTP do klienta wysyłającego żądanie (przeglądarka).
Application_PreSendRequestContent: pojawia się przed wysłaniem zawartości do klienta wysyłającego żądanie (przeglądarka).
Application_AcquireRequestState: pojawia się podczas pobrania bieżącego stanu (stanu sesji) związanego z bieżącym żądaniem.
Application_ReleaseRequestState: pojawia się podczas zakończenia wykonania obsługi wszystkich zdarzeń.
Application_ResolveRequestCache: pojawia się, kiedy zakończy się autoryzacja, by pozwolić modułom cachującym obsługiwać żądania z cachu obchodząc wykonania obsługi zdarzenia np. strony lub web serwisu.
Application_UpdateRequestCache: pojawia się po zakończeniu wykonania obsługi zdarzenia, by pozwolić modułom cachującym przechowywać odpowiedzi do obsługi kolejnych żądań.
Application_AuthenticateRequest: pojawia się, gdy moduł zabezpieczeń ustali tożsamość bieżącego użytkownika. Od tego momentu poświadczenia użytkownika są zatwierdzone.
Application_AuthorizeRequest: pojawia się, gdy moduł zabezpieczeń zweryfikuje, że użytkownik może uzyskać dostęp do zasobów.
Application_MapRequestHandler: pojawia się, gdy procedura obsługi jest wybrana do odpowiedzi na żądanie.
Application_PostLogRequest: pojawia się podczas zakończenia przetwarzania obsługi wszystkich zdarzeń dla zdarzenia LogRequest
Session_Start: pojawia się, gdy nowy użytkownik odwiedzi stronę aplikacji.
Session_End: pojawia się, gdy sesja użytkownika przekroczy limit czasu, zakończy się albo strona aplikacji zostanie opuszczona.

Warto o tym wiedzieć, bo być może kiedyś przyda nam się obsługa któregoś ze zdarzeń.

Dlaczego nie zwracać typu IQueryable w repo?

clip_image001 W ostatnim wpisie poruszyłem tematykę IoC i w przykładowym kawałku kodu dla LocationRepo znajduje się metoda GetLocations zwracająca typ IQueryable. Zwróciła na to uwagę pewna osoba odwiedzająca bloga i słusznie. Stwierdziłem więc, że lepiej będzie rozpisać się krótko na ten temat niż edytować poprzedni wpis. No więc dlaczego zwracanie typu IQueryable<T> jest złe? Można by powiedzieć, że zwracanie ogólnie jest złe i czasem się zdarza 😉 ale do rzeczy.

Implementując repozytorium powinniśmy tworzyć nową metodę dla każdego zapytania, np. GetLocationsByName, GetLocationsBySth, itd. Nie jest dobrą praktyką utworzenie jednej metody albo właściwości zwracającej całą kolekcję typu IQueryable<T>, po to by następnie filtrować elementy przy pomocy LINQ już poza repozytorium. Zapytania LINQ stosowane dla kolekcji IQueryable<T> są tłumaczone na drzewa wyrażeń, które następnie tłumaczone są na język określonego źródła danych, np. SQL. Zwracając z repozytorium taki typ, odpowiedzialność za tworzenie zapytań do źródła danych przechodzi na dewelopera implementującego kod w warstwie wyższej, warstwie domeny. W konsekwencji kod taki nie jest testowalny w 100%. Nie znamy wszystkich możliwych kombinacji zapytań, które mogą występować.
Kolejnym argumentem, który przemawia za niestosowaniem typu IQueryable w repozytoriach, jest to że uzależniamy nasze repozytorium od konieczności używania Entity Frameworka albo LINQ to SQL, ponieważ w przypadku innych źródeł danych musiałby być zaimplementowany mechanizm zwracania IQueryable. Chcemy aby nasz kod był uniwersalny i nie chcemy utrudniać sobie życia implementując dla każdego nowego źródła danych IQueryable, więc jedynym wyjściem jest unikanie tego typu. Oczywiście czasami może się on przydać, jednak musimy mieć to wszystko na uwadze 😉
Poniżej przykład metod zawartych w repozytorium.
Tak nie robimy

      public IQueryable<Location> GetLocations()
        {
            return _ctx.Locations.AsNoTracking();
        }

public IQueryable<Location> GetLocations()

{

return _ctx.Locations.AsNoTracking();

}

lepiej zróbmy to tak

public IEnumerable<Location> GetLocations(int page, int itemsPerPage)
        {
            return
                _ctx.Locations.AsNoTracking()
                    .OrderBy(l => l.Name)
                    .Skip(itemsPerPage*(page - 1))
                    .Take(itemsPerPage)
                    .ToList();
        }

        public Location GetLocationByName(string name)
        {
            return _ctx.Locations.SingleOrDefault(l => l.Name == name);
        }

public IEnumerable<Location> GetLocations(int page, int itemsPerPage)

{

return

_ctx.Locations.AsNoTracking()

.OrderBy(l => l.Name)

.Skip(itemsPerPage*(page - 1))

.Take(itemsPerPage)

.ToList();

}

public Location GetLocationByName(string name)

{

return _ctx.Locations.SingleOrDefault(l => l.Name == name);

}

Jak dodać kontener IoC?

Doctor with a syringe and patient. Isolated over white

Co to jest kontener IoC? IoC czyli Inversion of Control lub też odwrócenie zależności, brzmi bardzo ogólnie, ale co się pod tym kryje?
Możemy tutaj zaliczyć wzorzec fabryki, service locatora (lub też antywzorzec), czy też dependency injection i na tym ostatnim się skupimy.
Wzorzec ten może zostać zaimplementowany np. poprzez: constructor injection, property injection, jednak najbardziej sensowny jest ten pierwszy sposób.
Polega on na wstrzyknięciu zależności poprzez konstruktor. Kontener IoC ma nam w tym wszystkim pomóc, chodzi o to aby wstrzyknął on za nas jakiś konkretny typ, np. za typ ILocationRepo zostanie wstrzyknięty LocationRepo.

Po co nam to panie? No to zacznijmy od początku…
W przypadku web aplikacji ASP.NET MVC, domyślnie stworzony kontroler zawiera w sobie logikę, jednak dobrą praktyką jest wydzielenie warstwy logiki. W tym celu stworzyłem repozytoria w osobnym projekcie. Jednak aby wykorzystać dane repozytorium w kontrolerze, nie chcemy tworzyć instancji konkretnej klasy, chcemy być bardziej elastyczni i w razie potrzeby wstrzyknąć w to miejsce nową implementacje repozytorium. Do tego celu zastosujemy Dependency Injection i kontener IoC.

Pierwsza rzecz, która pozostaje do zrobienia to implementacja interfejsów dla każdego repozytorium oraz dla kontekstu. Tworzymy przykładowo interfejs dla repozytorium Location. Na razie zawiera on tylko metodę GetLocations(), jednak później będzie on zawierał więcej metod.

  public interface ILocationRepo
    {
        IEnumerable<Location> GetLocations();
    }

public interface ILocationRepo

{

IEnumerable<Location> GetLocations();

}

Implementujemy ten interfejs w klasie LocationRepo.

 public class LocationRepo : ILocationRepo
    {
        private readonly ITimePlannerContext _ctx;

        public LocationRepo(ITimePlannerContext ctx)
        {
            _ctx = ctx;
        }

          public IEnumerable<Location> GetLocations()
        {
            return _ctx.Locations.AsNoTracking().ToList();
        }
    }

public class LocationRepo : ILocationRepo

{

private readonly ITimePlannerContext _ctx;

public LocationRepo(ITimePlannerContext ctx)

{

_ctx = ctx;

}

public IEnumerable<Location> GetLocations()

{

return _ctx.Locations.AsNoTracking().ToList();

}

Widzimy tutaj także typ ITimePlannerContext – jest to interfejs naszego kontekstu, który także należy stworzyć, aby nie uzależniać się od konkretnego kontekstu w repozytoriach. Następnie możemy już przejść do kontrolera i stworzyć w nim konstruktor, który umożliwi nam constructor injection.

 public class LocationsController : Controller
    {
        private readonly ILocationRepo _repository;

        public LocationsController(ILocationRepo repository)
        {
            _repository = repository;
        }

        // GET: Locations
        public ActionResult Index()
        {
            var locations = _repository.GetLocations();
            return View(locations);
        }
}

public class LocationsController : Controller

{

private readonly ILocationRepo _repository;

public LocationsController(ILocationRepo repository)

{

_repository = repository;

}

// GET: Locations

public ActionResult Index()

{

var locations = _repository.GetLocations();

return View(locations);

}

Ok, ale skąd wiadomo jaką implementację wstrzyknąć pod dany interfejs? Do tego posłuży nam kontener IoC.

Jak dodać kontener IoC?
Poniżej przedstawię użycie kontenera Unity, jednak rozpocząłem też zabawę z Autofac i chyba w późniejszym czasie skorzystam z niego, ale o tym może później. Gdyby ktoś był ciekawy jak wypadają inne kontenery w porównaniu, szukając w sieci trafiłem na ciekawy link.
Teraz czas przedstawić jak zastosować Unity. Otwieramy NuGet package managera i wyszukujemy Unity.Mvc, instalujemy w naszej web aplikacji.

Po zainstalowaniu paczki, do folderu App_Start w naszej aplikacji zostaną dodane dwie dodatkowe klasy: UnityConfig i UnityMvcActivator. Przechodzimy do klasy UnityConfig i przystępujemy do implementacji metody RegisterTypes, w której zdefiniujemy które klasy implementują określone interfejsy. Kod całej klasy wygląda następująco.

	   public class UnityConfig
	    {
	        #region Unity Container
	        private static Lazy<IUnityContainer> container = new Lazy<IUnityContainer>(() =>
	        {
	            var container = new UnityContainer();
	            RegisterTypes(container);
	            return container;
	        });
	
	        /// <summary>
	        /// Gets the configured Unity container.
	        /// </summary>
	        public static IUnityContainer GetConfiguredContainer()
	        {
	            return container.Value;
	        }
	        #endregion
	
	        /// <summary>Registers the type mappings with the Unity container.</summary>
	        /// <param name="container">The unity container to configure.</param>
	        /// <remarks>There is no need to register concrete types such as controllers or API controllers (unless you want to 
	        /// change the defaults), as Unity allows resolving a concrete type even if it was not previously registered.</remarks>
	        public static void RegisterTypes(IUnityContainer container)
	        {
	            // NOTE: To load from web.config uncomment the line below. Make sure to add a Microsoft.Practices.Unity.Configuration to the using statements.
	            // container.LoadConfiguration();
	
	            // TODO: Register your types here
	            // container.RegisterType<IProductRepository, ProductRepository>();
	
	            container.RegisterType<AccountController>(new InjectionConstructor());
	            container.RegisterType<ManageController>(new InjectionConstructor());
	            container.RegisterType<ITimePlannerContext, TimePlannerContext>(new PerRequestLifetimeManager());
	            container.RegisterType<ILocationRepo, LocationRepo>(new PerRequestLifetimeManager());
	            container.RegisterType<IEventRepo, EventRepo>(new PerRequestLifetimeManager());
	        }
    }

public class UnityConfig

{

#region Unity Container

private static Lazy<IUnityContainer> container = new Lazy<IUnityContainer>(() =>

{

var container = new UnityContainer();

RegisterTypes(container);

return container;

});

/// <summary>

/// Gets the configured Unity container.

/// </summary>

public static IUnityContainer GetConfiguredContainer()

{

return container.Value;

}

#endregion

/// <summary>Registers the type mappings with the Unity container.</summary>

/// <param name="container">The unity container to configure.</param>

/// <remarks>There is no need to register concrete types such as controllers or API controllers (unless you want to

/// change the defaults), as Unity allows resolving a concrete type even if it was not previously registered.</remarks>

public static void RegisterTypes(IUnityContainer container)

{

// NOTE: To load from web.config uncomment the line below. Make sure to add a Microsoft.Practices.Unity.Configuration to the using statements.

// container.LoadConfiguration();

// TODO: Register your types here

// container.RegisterType<IProductRepository, ProductRepository>();

container.RegisterType<AccountController>(new InjectionConstructor());

container.RegisterType<ManageController>(new InjectionConstructor());

container.RegisterType<ITimePlannerContext, TimePlannerContext>(new PerRequestLifetimeManager());

container.RegisterType<ILocationRepo, LocationRepo>(new PerRequestLifetimeManager());

container.RegisterType<IEventRepo, EventRepo>(new PerRequestLifetimeManager());

}

W metodzie RegisterTypes jak sama nazwa wskazuje, rejestrowane są typy i tak np. za typ ILocationRepo podstawiamy LocationRepo, itd. W przypadku gdy stworzymy nową wersję LocationRepo i będziemy chcieli z niej korzystać, to wystarczy tylko ją tutaj zarejestrować i to wszystko. Oczywiście gdyby ktoś chciał można też wykorzystać w tym miejscu refleksję i wtedy zwolni nas to z obowiązku rejestrowania każdego nowego typu. Teraz możemy uruchomić aplikację i sprawdzić efekt. Bardzo proste prawda? Za to ile korzyści 😉

Do czego służy metoda AsNoTracking()?

Korzystając z Entity Frameworka warto zwracać uwagę na sposób pobierania danych.
W przypadku, gdy nie będziemy ich modyfikować, a chcemy jedynie pobrać dane tylko do odczytu, przydatna okaże się metoda AsNoTracking(). Wywołanie metody skutkuje brakiem śledzenia danych przez kontekst. Dzięki temu nie marnujemy niepotrzebnie zasobów.
Przyjrzyjmy się poniższemu przykładowi, w którym porównamy pobieranie danych z i bez metody AsNoTracking(). Na początek pobieramy dane standardowo. W tym celu modyfikujemy metodę Index() kontrolera LocationsController i debugując przechodzimy za linię kodu odpowiadającą za zwrócenie danych do widoku. W okienku watch podglądamy nasz obiekt kontekstu i widzimy, że 4 lokalizacje zostały do niego zapisane.

Teraz czas na wywołanie metody AsNoTracking() i upewnienie się, że dane nie są zapisywane w kontekście. Tym razem metoda Index() prezentuje się następująco:

public ActionResult Index()

{

var locations = _db.Locations.AsNoTracking();

return View(locations.ToList());

}

public ActionResult Index()

{

var locations = _db.Locations.AsNoTracking();

return View(locations.ToList());

}

Debugujemy, przechodzimy za ostatnią linię kodu w metodzie Index() i podglądamy nasz obiekt kontekstu.

Jak widać lokalizacje nie zostały tym razem zapisane do kontekstu, nie są przez niego śledzone. W tym przypadku oszczędności pamięci są niewielkie, ale wyobraźmy sobie gdybyśmy mieli takich lokalizacji tysiące, spowodowałoby to niepotrzebne straty. Dlatego należy zwrócić szczególną uwagę w takich sytuacjach i stosować AsNoTracking(), tam gdzie tylko jest to możliwe.

Exception has been thrown by the target of an invocation

Dodając kontroler – MVC 5 Controller with views, using Entity Framework. Możemy napotkać pewien problem.

Po kliknięciu Add pojawia się błąd: Exception has been thrown by the target of an invocation.

Googlując możemy znaleźć dosyć dużo osób mających taki sam problem, jednak większość proponowanych rozwiązań nie dawała w moim przypadku rezultatu, np. reinstalacja paczki EntityFramework. Niektórzy proponowali aktualizację Visual Studio, jednak tyczy się to tylko VS2013. Próbowałem nawet użyć VS2013, jednak było to samo. Rozwiązanie okazało się bardzo proste, wystarczyło edytować connection stringa w pliku Web.config. Wcześniej zmieniłem domyślną nazwę klasy kontekstu, ale nie wprowadziłem zmian do Web.configa.
Było:

<connectionStrings>

<add name="DefaultConnection" connectionString=……

</connectionStrings>

<add name="DefaultConnection" connectionString=……

</connectionStrings>

należało zmienić nazwę na dokładnie taką samą jak klasa kontekstu czyli:

<connectionStrings>

<add name="TimePlannerContext" connectionString=……

</connectionStrings>

<add name="TimePlannerContext" connectionString=……

</connectionStrings>

Ta da, działa!
Kontroler został utworzony jak również widoki. Błąd jest banalny, ale może ktoś napotka ten sam problem i dzięki temu wpisowi zaoszczędzi kilka minut Puszczam oczko

Entity Framework Code First Migrations

Entity Framework to kolejna generacja technologii firmy Microsoft, która zapewnia dostęp do danych. Jest to rozszerzona technologia ORM (ang. Object Rational Mapping), która ułatwia powiązanie danych w bazie danych z obiektami w aplikacji, poprzez stworzenie abstrakcyjnych modeli obiektowych w aplikacji z modeli relacyjnych lub logicznych. Dzięki temu możliwe jest tworzenie zapytań i manipulowanie danymi używając programowania zorientowanego obiektowo.
Używając Entity Framework możliwe są trzy podejścia do wyboru: Code First, Database First i Model First. Podejście Code First polega na zdefiniowaniu za pomocą kodu w języku C# typów odpowiadających modelowi danych, na podstawie którego zostanie wygenerowany schemat bazy danych. Przeciwieństwem jest podejście Model First, gdzie najpierw tworzy się model bazy danych korzystając z gotowego narzędzia w Visual Studio, a schemat bazy oraz odpowiadające mu klasy zostaną wygenerowane automatycznie przez Entity Framework. Database First z kolei polega na samodzielnym stworzeniu bazy danych, a następnie jej importowaniu, po czym tworzone są odpowiednie klasy.

Jak stworzyć bazę danych przy użyciu EF i podejścia Code First?
Tworzymy nowy projekt ASP.NET Web Application z szablonem Empty. Następnie przechodzimy do Nuget Package Managera i wyszukujemy pakiety takie jak widoczne na obrazku poniżej.

Kolejnym krokiem jest stworzenie modeli.

Poniżej przykład jednego modelu EventType.

public class EventType

{

[Required]

public string Id { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "TypeName")]

[Required]

public string Name{ get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "TypeDescription")]

public string Description { get; set; }

}

public class EventType

{

[Required]

public string Id { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "TypeName")]

[Required]

public string Name{ get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "TypeDescription")]

public string Description { get; set; }

}

Musimy także pamiętać o dodaniu klasy kontekstu. Kontekst musi zawierać także właściwości, które reprezentować będą tabele w bazie danych. W kontekście możemy dodatkowo przeciążyć metodą OnModelCreating, gdzie możemy wprowadzić trochę ustawień, np.:
usunięcie konwencji nazewnictwa tabel w liczbie mnogiej,

modelBuilder.Conventions.Remove<PluralizingEntitySetNameConvention>();

1	modelBuilder.Conventions.Remove<PluralizingEntitySetNameConvention>();

usunięcie konwencji usuwania kaskadowego,

modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

1	modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

czy też włączenie kaskadowego usuwania dla konkretnego powiązania między tabelami, za pomocą FluentAPI.

modelBuilder.Entity<Event>().HasRequired(e=>e.User).WithMany(u=>u.Events).HasForeignKey(e=>e.UserId).WillCascadeOnDelete(true);

1	modelBuilder.Entity<Event>().HasRequired(e=>e.User).WithMany(u=>u.Events).HasForeignKey(e=>e.UserId).WillCascadeOnDelete(true);

Prawidłowo stworzony kontekst w przypadku mojego projektu wygląda obecnie tak:

public class TimePlannerContext : IdentityDbContext<User>

{

public TimePlannerContext()

: base("DefaultConnection")

{

}

public DbSet<Event> Events { get; set; }

public DbSet<EventType> EventTypes { get; set; }

public DbSet<Location> Locations { get; set; }

public static TimePlannerContext Create()

{

return new TimePlannerContext();

}

protected override void OnModelCreating(DbModelBuilder modelBuilder)

{

base.OnModelCreating(modelBuilder);

modelBuilder.Conventions.Remove<PluralizingEntitySetNameConvention>();

modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

modelBuilder.Entity<Event>().HasRequired(e=>e.User).WithMany(u=>u.Events).HasForeignKey(e=>e.UserId).WillCascadeOnDelete(true);

}

}

public class TimePlannerContext : IdentityDbContext<User>

{

public TimePlannerContext()

: base("DefaultConnection")

{

}

public DbSet<Event> Events { get; set; }

public DbSet<EventType> EventTypes { get; set; }

public DbSet<Location> Locations { get; set; }

public static TimePlannerContext Create()

{

return new TimePlannerContext();

}

protected override void OnModelCreating(DbModelBuilder modelBuilder)

{

base.OnModelCreating(modelBuilder);

modelBuilder.Conventions.Remove<PluralizingEntitySetNameConvention>();

modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

modelBuilder.Entity<Event>().HasRequired(e=>e.User).WithMany(u=>u.Events).HasForeignKey(e=>e.UserId).WillCascadeOnDelete(true);

}

Gdy warstwę modelu mamy już stworzoną, możemy przystąpić do migracji, czyli aktualizacji struktury bazy danych lub raczej jej utworzenia, ponieważ jest to pierwsza migracja. W tym celu otwieramy konsolę Package Managera.

Upewniamy się żę Default project to ten dla którego chcemy włączyć migracje. Wpisujemy polecenie Enable-Migrations i dajemy enter.

Jeśli pojawi się błąd tak jak na poniższym obrazku, oznacza to że w którejś z encji zapomnieliśmy dodać właściwość Id.

W tym przypadku chodzi o klasę Location, tak więc dodajemy:

public class Location

{

public string Id { get; set; }

…

public class Location

{

public string Id { get; set; }

…

i wywołujemy polecenie raz jeszcze, ale tym razem konieczne jest dodanie parametru -Force:

Enable-Migrations -Force

1	Enable-Migrations -Force

w przeciwnym wypadku dostaniemy komunikat:

„Migrations have already been enabled in project ‚Repository’. To overwrite the existing migrations configuration, use the -Force parameter.”

Po dodaniu migracji do projektu zostanie dodany folder Migrations z klasą Configuration.cs.

Kolejny krok to wywołanie polecenia, które utworzy migrację startową. Spowoduje to utworzenie nowej klasy w folderze Migrations, dziedziczącej po DbMigration, która zawiera dwie metody Up() i Down(). Jak się można domyśleć metoda Up() zawiera zmiany jakie mają zostać wprowadzone w bazie danych, natomiast metoda Down() jest przeciwieństwem, czyli odwraca zmiany wprowadzone przez metodę Up().

Add-migration firstMigration

1	Add-migration firstMigration

Kolejny krok to aktualizacja bazy danych.

Update-Database

1	Update-Database

Teraz możemy sprawdzić efekt, otwierając Server Explorera z zakładki View. Jak widać tabele zostały utworzone. W przypadku wprowadzenia zmian w modelu i kolejnej migracji, struktura bazy danych zostanie zaktualizowana, bez utracenia danych w niej zawartych.

Time Planner–konfiguracja GitHuba z VS i stworzenie projektu

Korzystając z Visual Studio 2015 i GitHuba niezbędna będzie wtyczka, która nazywa się: GitHub Extension for Visual Studio. Dzięki niej można łatwo podpiąć repozytorium GitHuba do VS. Jak tego dokonać? Już prezentuję.

Z VS wybieramy Tools -> Extensions and Updates

Wybieramy grupę Online i wpisujemy w wyszukiwarce GitHub Extension for Visual Studio. Klikamy Download.

Następnie instalujemy rozszerzenie i restartujemy Visual Studio.

Przechodzimy do okienka Team Explorer, klikamy Manage Connections -> Connect to GitHub, podajemy dane swojego konta i klikamy Login.

Kiedy już się zalogujemy, tworzymy nowy projekt w VS. W tym przypadku, będzie to ASP.NET Web Application z szablonem MVC 5. Dodatkowo możliwe jest stworzenie projektu z testami jednostkowymi. Trochę też się zastanawiałem, czy jednak nie wykorzystać .NET Core 1.0 i MVC 6, jednak stwierdziłem, że jest to dopiero pierwszy release, bardziej okrojony od .NET 4.6, więc rozsądniej będzie wybrać MVC 5 i .NET Framework 4.6, a na pewno będzie łatwiej rozwiązywać napotkane problemy.

Gdy projekt zostanie utworzony, dodajemy go do naszego systemu kontroli wersji. Wpisujemy komentarz i wybieramy Commit. Spowoduje to commit lokalnie, nie oznacza to jeszcze, że zmiany znajdą się w repozytorium na serwerze. W tym celu można od razu wybrać Commit and Push lub przejść do opcji Sync.

Klikamy Get Started przy opcji GitHub, następnie uzupełniamy nazwę repo i klikamy Publish. Teraz kod znajduje się już na serwerze.

Co w przypadku dalszych commitów, gdy już dodamy trochę kodu? Postępujemy analogicznie. Wybieramy Source Control -> Commit, dalej postępujemy tak samo jak wyżej. Po commicie lokalnym, możemy wykonać push z opcji synchronizacji.

Teraz nie pozostaje nic innego jak zająć się kodowaniem 🙂

Time Planner–narzędzia

tool

W poprzednim poście opisałem tematykę projektu i wymieniłem technologie. Teraz czas na przedstawienie narzędzi. Zintegrowane środowisko programistyczne, które zostanie użyte to Microsoft Visual Studio w najnowszej wersji 2015 Enterprise (obecnie z Update 1). Dodatkowo nie obędzie się bez Resharpera, który pozwala na zwiększenie efektywności klepania kodu, czyli analizuje kod, pomaga eliminować błędy i code smells, a także usprawnia refaktoryzację. Przyzwyczaiłem się już trochę do tego toola, dlatego nie wyobrażam sobie już pracy bez niego 😛

Do kontroli wersji użyty zostanie Git, a repozytorium będzie dostępne na GitHubie (wynika to z regulaminu konkursu). Wcześniej nie miałem okazji korzystać z Gita, ponieważ nie było takiej potrzeby, przyzwyczaiłem się do TFSa i w sumie było mi z tym dobrze (wiem wiem zaraz znajdą się hejterzy :P). Także w końcu jest okazja poznać Gita 🙂 Repo projektu znajduje się pod tym adresem. Osoby niezwiązane z programowaniem, czy też początkujący programiści pewnie zastanawiają się po co komu system kontroli wersji. Już odpowiadam. Działa to tak, że po każdej implementacji kawałka kodu (zazwyczaj kompilującego się) wysyłamy nasz kod do repozytorium. Można ten zabieg wykonywać częściej lub rzadziej, ale zalecane jest jak najczęściej. Następnie możemy zająć się dalej kodowaniem i nawet jeżeli coś zepsujemy, to mamy ten przywilej, że w każdej chwili możemy wrócić do poprzedniej działającej wersji. Mało tego, możliwe jest porównywanie zmian w poprzedniej i aktualnej wersji oraz śledzenie postępu prac. Także bez Gita, TFSa, SVNa, itd. się nie obędzie przy pracy nad projektem. Należy także wspomnieć, że systemy kontroli wersji dzielą się na scentralizowane i rozproszone, ale to już temat na inny post. Z tych wymienionych wyżej – rozproszone: Git, scentralizowane: TFS, SVN.

Dodatkowo dobrze by było zrobić sobie backlog zadań, które mają zostać zrealizowane, tak aby o nich nie zapomnieć i móc śledzić postęp swoich prac. Do tego celu użyty zostanie TFS w wersji online. Dzięki temu, możliwe będzie również planowanie sprintów i wyznaczanie swojego capacity (tak będę Scrum Masterem, Product Ownerem i Developerem na raz 😀 zrobię sobie jednoosobowego Scruma, a co!).

Time Planner–Projekt open source

Witajcie! Jak już wspomniałem w pierwszym poście na blogu, rozpoczynam pracę nad projektem open source, który ma głównie na celu zapoznanie się z technologiami ASP.NET MVC, AngularJS, Azure i może przy okazji jeszcze coś się nawinie. Motywacją do prowadzenia bloga i projektu jest konkurs realizowany przez Macieja Aniserowicza – „Daj Się Poznać”. Już od dawna chciałem prowadzić własnego bloga (tak to głównie Maciej mnie zainspirował do tej działalności :)), jednak teraz dostałem trochę kopa motywacyjnego, ponieważ regulamin konkursu wyraźnie mówi: „minimum 2 posty techniczne tygodniowo” na blogu – ok to spróbuję. Ponadto projekt ma być prowadzony min. przez 10 tygodni. W całym tym konkursie nie chodzi mi w cale o wygranie nagrody, chce po prostu poznać technologie. Projekt, który będę realizował, też nie jest jakimś bardzo odkrywczym tematem, chodzi o stworzenie czegoś co ma ręce i nogi, co pomoże zdobyć trochę doświadczenia.

No dobra, a teraz do rzeczy. Projekt open source, który będę tworzył nazwałem roboczo: TimePlanner. Zamysł jest taki, żeby stworzyć portal umożliwiający zaplanowanie wolnego czasu, poprzez tworzenie spotkań, wydarzeń, przeznaczony dla osób, które mają wolny czas, ale nie wiedzą gdzie i z kim wyjść, itp. Dla kogo to może być użyteczne? Wyobraźmy sobie sytuację, że przeprowadzamy się do nowego miasta i nie mamy w nim znajomych, a chcielibyśmy kogoś poznać, wyjść z kimś na piwo, niekoniecznie umawiać się na randki 😉 Wchodzimy więc na ten portal dodajemy ogłoszenie, a inni użytkownicy mogą je zobaczyć i dołączyć się do tzw. eventu, oczywiście uwzględniając lokalizację, itp. Zauważyłem, że w ostatnim czasie wiele tego typu ogłoszeń pojawia się na facebooku, więc pomyślałem, że może komuś się to przyda i coś z tego się urodzi i nie będzie to kolejny projekt do szuflady. Czas pokaże, zobaczymy…

Kolejne posty będą bardziej techniczne, chociaż nie wykluczam, może pojawią się też jakieś o bardziej miękkiej tematyce, a tymczasem trzeba przygotować narzędzia do pracy i zacząć działać 🙂

Zachęcam do śledzenia mnie na twitterze i facebooku, będę tam umieszczał informacje o pojawieniu się nowych wpisów na blogu 😉

P	W	Ś	C	P	S	N
« Maj
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Jakub Skoczeń

.NET Developer

Category Archives: TimePlanner

Do czego służy plik Global.asax?

Dlaczego nie zwracać typu IQueryable w repo?

Jak dodać kontener IoC?

Do czego służy metoda AsNoTracking()?

Exception has been thrown by the target of an invocation

Entity Framework Code First Migrations

Time Planner–konfiguracja GitHuba z VS i stworzenie projektu

Time Planner–narzędzia

Time Planner–Projekt open source