C# JSON projekt Rozwiązania

Artykuł o nim
http://commitandrun.pl/2016/04/25/Dlaczego_Entity_Framework_nie_jest_dobrym_wyborem/
i weś tu wybierz.

Cytat z tamtad
Własna matematyka
To moja absolutnie ulubiona rzecz w EF. :)

Klasa ma właściwość typu decimal a kolumna w bazie jest typu decimal(18,2). Jeśli ustawimy właściwości wartość np. 20.4777, co się znajdzie w bazie po insercie? Oczywiście 20.47. Dlaczego nie 20.48, jak nakazuje matematyka? Tego nie wiadomo. Żeby było śmieszniej, w czystym ADO.NET działa to dobrze. A EF przecież z niego ponoć korzysta… Niestety nie mam pojęcia jak twórcy EF zhackowali działanie ADO.NET, że to przestało działać, ani kto to testował. ( Może ktoś z ZUS? ;)

Żeby było jeszcze śmieszniej, to nie zostało naprawione - ale w wersji 6.ileś dodano flagę włączającą prawidłowe zaokrąglanie.

Jakby nie patrzeć, żaden inny ORM nie daje możliwości wyboru między stosowaniem matematyki a jej ignorowaniem. Miłośnicy trójkątków o czeterech bokach i dzielenia przez zero powinni być szczęśliwi. ;)
Poważny argument przeciw.
Nie orientuję się ale chyba ADO.net nie jest zbyt wydajne?

Nie ma nic wydajniejszego niż ADO.NET w .NET, bo to jest warstwa najbliżej bazy danych i ORMy bazują na ADO.NET właśnie.

ADO.NET poza tym nie jest rozwiązaniem Twojego problemu. Użyj NHibernate z Fluent NHibernate do konfigurowania albo np. Dappera: https://github.com/StackExchange/Dapper - tylko ten ma sens jeśli już masz bazę danych.

Z obiektówki pewnie tak, ale czy ado.net nie korzysta z libpq-fe ?

Korzysta z Npgsql, który jest data providerem dla PostgreSQL dla .NET.

A Npgsql z czego korzysta?
Przypadkiem nie z libpq-fe -> lib Postgresql FrontEnd.

Nie wiem, zdekompiluj sobie i sprawdź.
I w ogóle jakie to ma znaczenie? Dopóki nie ma innej alternatywy i tak musisz tego używać łącząc się z PostgreSQL w .NET.

karol75 napisał(a):

Co złego widzisz w klepaniu z palca SQL-a?

Jakiekolwiek zmiany w bazie danych mogą rozwalić działanie aplikacji, bo zapomnisz gdzieś poprawić nazwę pola. Jedynym zabezpieczeniem będą czasochłonne (i do napisania, i do uruchamiania) testy integracyjne.
Jeśli używasz ORM, to odświeżasz model bazy i próbujesz skompilować projekt. Wszystkie miejsca w kodzie, gdzie zapomniałeś o zmianie nazwy pola, jego typu itp. natychmiast dostaniesz jako błędy kompilacji.

Kiedyś uczestniczyłem w takim projekcie, jedna osoba klepała bazę danych, a inni pisali soft. Każde odświeżenie modelu Entity Framework powodowałoz źe projekt przestawał się kompilować, trzeba było ręcznie edytować pliki wygenerowane przez Entity Framework. Wszystko zwalano na to, że to MySQL do d**y jest i jego provider dla .net. O podejściu "code first" nikt nigdy w życiu nie słyszał, no może z jedna osoba słyszała, ale i tak wszyscy zgodnie upierali się, że bazę to trzeba ręcznie stworzyć, a potem aplikacja ma się z nią łączyć i basta.

Niektórzy jeszcze pośmiewali się, że .net jest do d**y i po co orm, bo kiedyś w Delphi klepano sql-e zaszyte na żywca w kodzie i było dobrze, a my w .net to wiecznie tylko mieliśmy jakieś problemy, nieznane nigdzie indziej

No i zaczęły się schody.

Moja "architektura"
System "Pluginów" MEF
Program główny wczytuje katalog i wczytuje odpowiednie pluginy.
A w zasadzie jeden plugin, który tworzy dokumenty.
Program główny dostaje interfejs.

    public interface IDokument
    {
        //własciwości organizacyjne
        void show();
        void Delete();
...
        //Właściwości dokumentu
        //nagłówek
        int miesiac { get; set; }
        int rok { get; set; }
        string NumerDokumentu { get; set; }
        DateTime datarej { get; set; }
        DateTime datadok { get; set; }
        DateTime datapod { get; set; }
        bool dokwwal { get; set; }
...
}

NHibernate wymaga aby właściwości zapisywane (odwzorowywane) w bazie były abstrakcyjne.
Klasa implementująca musi mieć właściwości publiczne.
I teraz pytanie jak to połączyć?

karol75 napisał(a):

NHibernate wymaga aby właściwości zapisywane (odwzorowywane) w bazie były abstrakcyjne.

Nie.

Klasa implementująca musi mieć właściwości publiczne.

No raczej. Ale to chyba nie problem?

I teraz pytanie jak to połączyć?

Ale połączyć co z czym? I po co ten interfejs?

somekind napisał(a):

karol75 napisał(a):

NHibernate wymaga aby właściwości zapisywane (odwzorowywane) w bazie były abstrakcyjne.

Nie.

Możesz to rozwinąć?
Wszystkie opisy w sieci stawiają ten wymóg.

A pokażesz linka do takiego opisu?

Pomijając już kwestie ORM itd. Dlaczego pisząc w .NET używasz konwencji nazw z Delphi ? Przecież to wygląda tragicznie. Nie chcę wyrokować nie widząc całości, ale po prókach kodu które podrzuciłeś, zaczynam mieć wątpliwości czy takie przepisywanie w ogóle ma sens. Próbujesz tam użyć WCF ? Masz takie wymaganie, jakiś zewnętrzny system z tego korzysta ?

W2K napisał(a):

Pomijając już kwestie ORM itd. Dlaczego pisząc w .NET używasz konwencji nazw z Delphi ?

Przyzwyczajenia, i w zasadzie brak nawyków .NET

W2K napisał(a):Przecież to wygląda tragicznie. Nie chcę wyrokować nie widząc całości, ale po prókach >kodu które podrzuciłeś, zaczynam mieć wątpliwości czy takie przepisywanie w ogóle ma sens.

W Delphi może z mojej winy może nie, Sypie Mi stale AccessViolation związanymi z BPL-ami i za Chiny Ludowe nie mogę dojść dlaczego.
Jest to system tylko dla mnie (używam go w firmach w których pracuję) , dodatkowo wydać kilka tysięcy zł na system non-profit to trochę za dużo. Jakiś czas temu kupiłem Licencję Delphi XE2 Pro i na tym bazuję.

W2K napisał(a):Próbujesz tam użyć WCF ?

Nie to nie WCF zależności nie posprzątałem. Okienka to Windows Forms.

W2K napisał(a):Masz takie wymaganie, jakiś zewnętrzny system z tego korzysta ?

Tak, to w zasadzie jest "jądro" systemu księgowego i inne programy mają z niego korzystać w ramach jednego komputera, max sieć lokalna ewentualnie VPN.

Cały pomysł polega na tym aby mieć Jądro dokumentów księgowych(plankont) z których inne programy będą korzystać na podobnej zasadzie jak ActiveX, ale ma to być Program także samodzielny.

W Delphi Mam to w zasadzie zrobione, ale nie mogę opanować Błędów i dochodzę powoli do wniosków iż Delphi po prostu więcej Mi przeszkadza niż pomaga.
Nowe wymagania, więcej i szybciej można zrobić w VS niż Delphi.

A może Ja to źle robię.
Pluginy oparłem na MEF
Dokumenty widzę jako interfejsy -> Łatwo przerobić na serwer Automatyzacji.
Może jest lepszy sposób na taki system?

lampasss napisał(a):

Rób tak aby było Ci lepiej, ale nie zwalaj na Delphi, jeśli i tak klepiesz formatki :)

Moim pierwszym Językiem Jest ObjectPascal w zasadzie Pascal.
Podpowiedz Jak ty byś zrobił taki system?
To nie obrażanie się tylko realne pytanie.

somekind napisał(a):

A pokażesz linka do takiego opisu?

https://blog.soltysiak.it/pl/2016/07/nhibernate-automatycznie-sprawdz-czy-properties-sa-virtual/
http://plukasiewicz.net/Artykuly/NHibernate
http://blog.blueage-software.com/post/Teoretyczne-wprowadzenie-do-NHibernate.aspx

Ja nie do końca rozumiem, czemu to przepisujesz. Jakbyś powiedział, że np. masz w delphi aplikację desktopową, a potrzebujesz webową, to ok, wybrałeś C# i coś tam tworzysz, ale wybrałeś raczej windows forms, które są w odwrocie, dodatkowo dopiero się 'uczysz' tego c#, więc efekt końcowy formatek w C# może być jeszcze gorszy od tego co masz teraz.
Struktura systemu tez jest nie do końca jasno przedstawiona, w 3 zdaniach tego nie przedstawisz sensownie, więc mozesz opisać problem szerzej w innym wątku nawet. Ale obawiam się, że już podjąłeś decyzję.

karol75 napisał(a):

https://blog.soltysiak.it/pl/2016/07/nhibernate-automatycznie-sprawdz-czy-properties-sa-virtual/
http://plukasiewicz.net/Artykuly/NHibernate
http://blog.blueage-software.com/post/Teoretyczne-wprowadzenie-do-NHibernate.aspx

No, i tam wszędzie jest mowa o tym, że mają być wirtualne, a nie abstrakcyjne.
I nie jest prawdą, że bezwzględnie muszą, to jest wymagane jeśli chcemy aby działał lazy loading i interceptory.

somekind napisał(a):

karol75 napisał(a):

https://blog.soltysiak.it/pl/2016/07/nhibernate-automatycznie-sprawdz-czy-properties-sa-virtual/
http://plukasiewicz.net/Artykuly/NHibernate
http://blog.blueage-software.com/post/Teoretyczne-wprowadzenie-do-NHibernate.aspx

No, i tam wszędzie jest mowa o tym, że mają być wirtualne, a nie abstrakcyjne.
I nie jest prawdą, że bezwzględnie muszą, to jest wymagane jeśli chcemy aby działał lazy loading i interceptory.

Tak oczywiście masz racje pomyliłem.