Diwebsity

KendoUI Grid control is very flexible and powerful widget to present table data. It provides us a set of useful features. All of them is described very well in Kendo Grid documentation. However there is some cases that these possibilities is not enough to fulfill our requirements.

KendoUI Grid support filters and sorting data in user interface. These filters can do some complex logic. Especially if we decide to pass them to API layer and evaluate server side. Let’s imagine that user set a complex filtering and sorting rules that helps him to manage his data. Then he move to another page and when he want to get back he have to set all filters again.

When I first try to write test for class that use directly, I found that I can’t mock database context directly using for example Moq library. That’s because this class properties isn’t virtual. After some research I found that EF6 could be set up to enable mocking [1,2]. However that is not quite what I need. I had some specific requirements:

1. I want to trace operations into database tables
2. It must work for Code First EF6 configuration
3. It should be generic solution for each database table

Po dokładnym opisaniu mechanizmu czas na przedstawienie planowanej architektury implementowanego przeze mnie rozwiązania. Warto też zdefiniować cel projektu oraz zestaw kroków, które zawiodą mnie do jego wykonania.

Zacznijmy więc od zdefiniowania funkcjonalności, które chcemy osiągnąć w projekcie. Oczywiście można założyć, że docelowo chcielibyśmy zaimplementować spójny mechanizm OWASP AppSensor w pełnym jego zakresie, z implementacją wszystkich zdefiniowanych punktów detekcji i integracji z innymi systemami. Jednak z doświadczenia wiem już, że ten sposób określania wymagań nie jest dobry, bo dość słabo motywuje do pracy i do skończenia projektu. Zamiast tego zdefiniujemy MVP naszego projektu.