Autor Wątek: PHP+MySQL już w lamusie - co teraz?  (Przeczytany 20881 razy)

Offline lethern

  • Użytkownik

# Marzec 12, 2015, 19:06:44
Wrzucam kod (example ze strony) raczej jako ciekawostkę, ale spodobało mi się, że wszystko zrobione jest w jednym pliku widoku (bez żadnego kodu "backującego")
wynikowy screen
http://i.imgur.com/vR3VLJn.jpg
cały projekt
<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation debug="true" strict="false" explicit="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
  <connectionStrings>
    <add name="NorthwindConnectionString" connectionString="Data Source=.\;Initial Catalog=Northwind;Integrated Security=True;"  />
  </connectionStrings>
</configuration>
<%@ Page Language="VB" %>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>ASP.NET Example</title>
</head>
<body>
  <form id="Form1" runat="server">
    <table cellspacing="10">
      <tr>
        <td>
          <asp:GridView ID="GridView1" runat="server" DataSourceID="Customers" AutoGenerateColumns="False"  DataKeyNames="CustomerID">
            <Columns>
              <asp:CommandField ShowSelectButton="True" />
              <asp:BoundField DataField="ContactName" HeaderText="ContactName" />
              <asp:BoundField DataField="CompanyName" HeaderText="CompanyName" />
            </Columns>
          </asp:GridView>
        </td>
        <td valign="top">
          <asp:DetailsView ID="DetailsView" runat="server" DataSourceID="Details" AutoGenerateRows="false" DataKeyNames="CustomerID" >
            <HeaderStyle BackColor="Navy" ForeColor="White" />
            <Fields>
              <asp:BoundField DataField="CustomerID" HeaderText="CustomerID"  ReadOnly="True" />
              <asp:BoundField DataField="ContactName" HeaderText="ContactName" />
              <asp:BoundField DataField="ContactTitle" HeaderText="ContactTitle" />
              <asp:BoundField DataField="CompanyName" HeaderText="CompanyName" />
              <asp:BoundField DataField="City" HeaderText="City" />
              <asp:BoundField DataField="Region" HeaderText="Region" />
              <asp:BoundField DataField="PostalCode" HeaderText="PostalCode" />
              <asp:BoundField DataField="Country" HeaderText="Country" />
            </Fields>
          </asp:DetailsView>
        </td>
      </tr>
    </table>
    <asp:SqlDataSource ID="Customers" runat="server"
      ConnectionString="<%$ ConnectionStrings:NorthwindConnectionString %>"
      SelectCommand="SELECT [CompanyName], [ContactName], [CustomerID] FROM [Customers]">
    </asp:SqlDataSource>
    <asp:SqlDataSource ID="Details" runat="server"
      ConnectionString="<%$ ConnectionStrings:NorthwindConnectionString %>"
      SelectCommand="SELECT * FROM [Customers] WHERE ([CustomerID] = @CustomerID)">
      <SelectParameters>
        <asp:ControlParameter ControlID="GridView1" Name="CustomerID" PropertyName="SelectedValue" Type="String" />
      </SelectParameters>
    </asp:SqlDataSource>
  </form>
</body>
</html>

Baza danych wzięta też z gotowca (tj. skrypt do generowania bazy używanej w przykładach na msdn, link)

Kod - gotowiec - skopiowany ze strony MSDN link z trzeciego (ostatniego) przykładu

Odpalane w (genialnym) visual studio, które ostatnio jest darmowe w wersji full (tj. VS 2013 community)
Chciałem dać kolejną opcję do rozważenia (i pokazać, że ASP.NET też można pisać "minimalnie", bez nawet linijki w C# etc. Można pisać studiująć jedynie przykłady na MSDNie + doczytująć na StackOverflow)

PS Podoba mi się, że nie tylko mechanizmy ASP.NET ze sobą dobrze współgrają (typu data binding), ale i z javascript, rzeczy typu np. JSON czy Ajaxy wykonywane są automatycznie w tle, plus jak ktoś się uprze, może łączyć skrypty html/JS z kodem ASP.NET, umieszczany w <% %>, np.
<div class="panel_content">
                <ul class="lista">
                    <% if (Uzytkownik.Instance != null && targetId != Uzytkownik.Instance.Id) { %>
                    <li><a href="<%= Page.ClientScript.GetPostBackClientHyperlink(Page, "Dodaj_0") %>"><span>Przydziel</span></a></li>
                    <% } %>
                    <li><a href="Zapros.aspx"><span>Zaproś</span></a></li>
                </ul>
            </div>

PPS co do ORM... ya heard about LINQ?
« Ostatnia zmiana: Marzec 12, 2015, 19:56:17 wysłana przez lethern »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline bies

  • Użytkownik

# Marzec 12, 2015, 19:55:20
Odniosę się tylko do dwóch rzeczy, może się komuś przyda:

Ad 4. To ty jakieś herezje głosisz... Nie jestem zwolennikiem mnożenia warstw. Ale pisanie dzikich sql w jakimkolwiek projekcie powyżej 200 roboczogodzin to szaleństwo. Bez mierzenia możesz na drzewo się z tą wydajnością schować. O braku podstawowych "featurów" nie wspominając:
- powodzenia w "bezpiecznym" parametryzowaniu kilkupoziomowych zapytań(filtry, grupowanie, sortowanie, stronicowanie, wybieranie kolumn)...
- batchowanie
- wiele zapytań/rezultatów w jednym roundtripie
- transakcje
- ZARZĄDZANIE KODEM
- no i weź napisz chociaż na tyle dobrego sqla co ORM...
Primo: napiszę (naprawdę, używam różnych SQL-i od 99r). Problemy z transakcjami? A co tam jest trudnego? Secundo: SAP, 240 milionów linii kodu aplikacyjnego w języku ABAP którego częścią jest Open SQL. Czyli, de facto, zanurzone selecty w kodzie. Pisanego przez, średnio, bardzo kiepskich programistów. A zakres obsługiwanej funkcjonalności jest niewyobrażalny nawet na pierwsze trzy tysiące rzutów oka. Nigdzie nie ma żadnych ORM-ów. Co więcej, nigdy nie będzie bo obecna metoda się sprawdza! Tertio: właśnie migruję projekt z JPA na JDBC i upraszczam ogólnie: na razie przy porównywalnej funkcjonalności zredukowałem 50 KLOC do 5KLOC (tak, dziesięć razy mniej kodu).

raporty w SQL... hmm...
Oczywiście. Hurtownie danych, raportowanie biznesowe w dużej skali. Np. raporty do konsolidacji finansowej robione nierzadko z wielu różnych źródeł (różne bazy, różne systemy). To cała masa SQL-a i mechanizmów integracyjnych.

Ogólnie: SQL jest bardzo dobrym i sprawdzonym sposobem operacji na danych. I działa niesamowicie dobrze w zastosowaniach przekraczających cokolwiek co obecne ORM-y są w stanie udźwignąć. Optymalizacja przeglądania dwóch powiązanych tabel przez otwarcie dwóch kursorów i przesuwanie ich w powiązaniu to podstawy w pewnych środowiskach.

Wreszcie, przerzucanie roboty do klienta jest OK do momentu gdy userzy zaczną ci narzekać, że otwarcie twojej strony potraja im zużycie baterii w telefonie :)
Na telefony pisze się właśnie appki natywne. Wtedy, jak wspomniałeś, backend na JSON-ie doskonale się sprawdza.

// edit
Ja wiem, że szerzę ,,herezje''. Luz, nie chodzi mi o to aby kogoś przekonywać. Być może po prostu komuś się coś z mojego doświadczenia przyda.
« Ostatnia zmiana: Marzec 12, 2015, 20:12:02 wysłana przez bies »

Offline Snejk47

  • Użytkownik

  • +3
# Marzec 12, 2015, 20:09:05
spodobało mi się, że wszystko zrobione jest w jednym pliku widoku

Ja pierdole.

Cały ten temat to istne "ja pierdole".

Offline lethern

  • Użytkownik

  • +5
# Marzec 12, 2015, 20:16:31
Ja pierdole.

Cały ten temat to istne "ja pierdole".
Jak to chyba ktoś już cytował
Błogosławiony ten, co nie mając nic do powiedzenia, nie obleka tego faktu w słowa.
« Ostatnia zmiana: Marzec 12, 2015, 20:18:20 wysłana przez lethern »

Offline ArekBal

  • Użytkownik

# Marzec 12, 2015, 20:52:58
Konkrety dajesz Snejk47!!!

to bies:
50 kloc do 5 kloc? Ja nie wiem gdzie tobie ORM produkował nadmiarowe linie kodu...  przykład?
Sama idea ORM jest efektem rozwiązywania problemów podejścia o którym mówisz.

Cytuj
SAP, 240 milionów linii kodu aplikacyjnego w języku ABAP
SAP ma swoje lata. Powyżej pewnego rozmiaru to jest droga bez powrotu. Jedynie zupełnie nowe rzeczy możesz inaczej robić. O ORM oni nie słyszeli gdy zaczynali.

Cytuj
Hurtownie danych, raportowanie biznesowe w dużej skali. Np. raporty do konsolidacji finansowej robione nierzadko z wielu różnych źródeł (różne bazy, różne systemy). To cała masa SQL-a i mechanizmów integracyjnych.
Hurtownie danych to albo OLAP, mdx, kostki i analiza wielowymiarowa albo wolna amerykanka(różne bazy nie tylko relacyjne, co któremu producentowi rozwiązania akurat pasuje). Nic to nie wnosi do dyskusji dziki SQL z readerami vs ORM.

To OLDSCHOOL ale jeśli ty tworzysz systemy w oparciu o tą rzeczywistość to rujnujesz przyszłość wielu informatyków.

do KK:

todomvc.com

;)

Rozstaw sobie jakiś duży framework(Zend, Symfony, CodeIgniter) i masz z głowy serwer. Większość roboty to dzisiaj klient.
« Ostatnia zmiana: Marzec 12, 2015, 20:57:36 wysłana przez ArekBal »

Offline Kos

  • Użytkownik
    • kos.gd

  • +3
# Marzec 13, 2015, 20:49:14
Ojezusmaria, orm vs raw SQL na warsztacie? :<

Pewnie że wszystko ma swoje miejsce, ale ORM-y są super popularne i raczej nie dałbym sobie wcisnąć że przyjeły się przez przypadek.
Używam na co dzień super-podstawowych modeli z Django i czuję że oszczędzają naprawdę dużo pisania, szczególnie w kontekście apki z mnóstwem małych tabeli i losowych powiązań.
Ale już odłóżmy na bok oszczędzanie kodu. ORM-y się przydają, bo pozwalają traktować zapytania jako dane. I tak jedno miejsce w kodzie może wystawić "Posty widoczne dla aktualnego usera", drugie je może przefiltrować po tych co mają >5 punktów (z joinem po tabeli votes), trzecie sobie przestronicuje, a czwarte zamiast tego po prostu zapyta o liczbę. Właściwe zapytanie zostanie zbudowane dopiero, gdy wynik będzie potrzebny.
Taki model jest nawet w Django całkiem elastyczny i w zależności od apki wygenerujesz sobie lekko 95%-99% kwerend. Jak weźmiesz coś poważniejszego typu SQLAlchemy, to pewnie dużo więcej.

Offline wozix

  • Użytkownik

  • +2
# Marzec 13, 2015, 23:17:19
Ja pierdole.

Cały ten temat to istne "ja pierdole".

No chyba "ja pie*dole! jaki super przegląd różnych technologii i do tego wszystko fajnie porównane!"

Offline jpacanowski

  • Użytkownik
    • http://jpacanowski.pl/

  • +1
# Grudzień 13, 2015, 20:10:05

Offline świrus

  • Użytkownik
    • Tu trolluje

# Grudzień 14, 2015, 16:21:50
Przykładowo: chcę napisać prywatną webową appkę która ma być listą ToDo - dodaj wpis, edytuj wpis, usuń wpis, zaznacz zrobione/niezrobione i NIC więcej (appka nie będzie dalej rozwijana). Za to co ważne - chcę żeby to było bezpieczne i zrobione SZYBKO i PROSTO. Czekam na sugestie. :)
https://www.firebase.com/ + https://material.angularjs.org + https://angularjs.org/
Szybciej i łatwiej się nie da dobra, da się, ale to już hipsteriada na całego..
Minusem jest vendor lock-in.

http://todomvc.com/examples/firebase-angular/#/
« Ostatnia zmiana: Grudzień 14, 2015, 16:58:04 wysłana przez świrus »

Offline Kos

  • Użytkownik
    • kos.gd

# Grudzień 14, 2015, 17:07:30
Jest jakiś opensourcowy odpowiednik firebase (baza danych json z uprawnieniami i powiadomieniami o zmianach)? Widzę dziurę na rynku.

Offline świrus

  • Użytkownik
    • Tu trolluje

# Grudzień 14, 2015, 19:52:46
Jest jakiś opensourcowy odpowiednik
Nie ma...

Chociaż, może kiedyś to będzie alternatywą: http://hood.ie/

Offline ShadowDancer

  • Redaktor

# Grudzień 14, 2015, 20:38:19
Konkrety dajesz Snejk47!!!
Pierwsza reakcja analogiczna jak Snejk'a, może dlatego, że przez pewien czas pracowałem w takim kodzie. Spróbuj utrzymać kod, który ma bazę zaszytą w widoku, logikę sprzęgniętą w codebehind gridview'a, 30 opcji konfiguracyjnych i korzysta z tego np. 40 klientów, krzyżyk na drogę ;)



Nie sądzę, bo serwer siedzi na Linuxie. Za to z rozwiązań linuxowych prawdopodobnie jestem w stanie postawić wszystko zważywszy że ostatnio przez PHPShell skompilowałem i uruchomiłem na serwerze Hello World w C++.
C# i Asp.Net śmiga na linuksie
« Ostatnia zmiana: Grudzień 14, 2015, 20:40:30 wysłana przez ShadowDancer »