Proč byste už neměli platit za web od počtu stránek (a za e-shop od počtu produktů)
Když dnes poptáte firemní web nebo e-shop, řada agentur vám zašle ceník odstupňovaný podle objemu. Základní web s pěti stránkami stojí X, deset stránek stojí Y. E-shop do 500 produktů vyjde na jednu částku, nad 5 000 položek si výrazně připlatíte. Zní to logicky, dokud si neuvědomíte jednu zásadní věc: v moderním softwaru je technologicky úplně jedno, jestli databáze vypisuje pět položek, nebo padesát tisíc.
Klam fyzického skladu u e-shopů a webů
Zákazníci příplatky za počet produktů často akceptují, protože si databázi podvědomě představují jako fyzický prostor. Postavit halu pro deset tisíc palet stojí víc než regál pro padesát krabic. V softwaru to ale neplatí. Pokud platíte „za kus“, platíte s největší pravděpodobností za špatnou architekturu, manuální opičí práci a skryté nešvary zastaralých systémů. Moderní platformy se totiž nestaví jako sbírka ručně formátovaných dokumentů.
Konec éry „kopírovat a vložit“
Přístup, kdy agentura účtuje každou novou stránku, většinou znamená použití vizuálních „klikátek“. Každou novou službu musí někdo otevřít, ručně naskládat bloky s textem a doladit formátování. Vytvoření dvacáté podstránky tak znamená další hodiny zbytečně účtované práce. Tvorba modulů na míru v robustním backendu naproti tomu znamená jednorázovou investici do infrastruktury.
Za co tedy u legacy systémů vlastně připlácíte?
- Daň za špinavá data: Neúčtují vám robustní systém, ale hodiny hrubé síly strávené čištěním vašich excelových tabulek a manuálními importy, protože systém nemá čisté API napojení na vaše ERP.
- Výkonnostní limity špatné architektury: Na běžných krabicových řešeních (např. WooCommerce) znamená skok na 10 000 položek drastický propad rychlosti administrace i frontendu.
- Cenová diskriminace: Je to primitivní filtr. Obrovský sortiment většinou znamená zavedenou B2B firmu. Cena tu vůbec nereflektuje technologickou složitost, ale čistě jen kupní sílu zákazníka.
| Aspekt vývoje | Zastaralý přístup (Platba za "kus") | Enterprise Architektura (.NET / Orchard) |
|---|---|---|
| Přidání 100. produktu/stránky | Manuální úprava HTML, skládání bloků v page builderu | Automatické vygenerování šablony z datového modelu |
| Výkon při 50 000 položkách v administraci | Pomalé načítání, pády prohlížeče, nutnost extra cache | Milisekundy díky Syncfusion UI virtualizaci |
| Přidání nového parametru (např. "Ekologický štítek") | Hromadná manuální editace stovek stránek | Jednorázové přidání ContentPart do definice typu |
Jak funguje skutečné řízení obsahu pod kapotou
Skutečně robustní enterprise platforma, jako je Orchard Core, přistupuje k vývoji z opačného konce. Místo prázdného plátna stavíme striktní datové struktury.
ContentType (Typy obsahu)
Nekóduji padesát stránek poboček ani produktů. Vytvořím striktní datový typ (např. pobočka má vždy adresu a fotogalerii). CMS se samo postará o renderování. Přidání tisící pobočky vás vývojově nestojí ani korunu.
ContentPart (Stavebnice)
Chcete k 500 produktům přidat parametr "Výprodej"? V moderní architektuře nevytvářím 500 úprav. Vytvořím znovupoužitelný modul (`ContentPart`) a připojím ho k typu. Rázem mají všechny položky nové pole a HTML na webu se automaticky aktualizuje.
Widgets & Syncfusion UI
Obsah i rozsáhlá data (desítky tisíc řádků v B2B) reagují na chování uživatele automaticky. Namísto statického textu programuji chytré Widgety a administraci zrychlím pomocí ASP.NET komponent (Syncfusion DataGrid), které zvládnou jakýkoliv objem dat.
Ukázka: Technická elegance v C#
Místo "vyklikávání" každé jedné stránky se v Orchard Core jednou nadefinuje architektura. Takto v C# vytvářím strukturu, která obslouží 10 i 100 000 produktů se stejnou lehkostí:
// Infrastruktura na prvním místě: Definice produktu pomocí Orchard Core Migrations
public int Create()
{
_contentDefinitionManager.AlterTypeDefinition("B2BProduct", type => type
.Creatable()
.Listable()
.WithPart("TitlePart", part => part.WithPosition("1")) // Název
.WithPart("ProductDetailPart", part => part.WithPosition("2")) // Naše custom data (SKU, Cena)
.WithPart("EcoLabelPart", part => part.WithPosition("3")) // Modulární štítek pro všechny
);
return 1;
}
Pokud tuto striktní byznys logiku na frontendu spojíme například se zmíněnými Syncfusion komponentami podporujícími OData adaptéry, i přidání desetitisící položky představuje jen zápis do databáze, který se do webu propíše v řádu milisekund.
