Blazor Server و WebAssembly
رندر به هر حال سمت سرور است. در Server فراخوانی مستقیم است؛ در WebAssembly فراخوانی open را بهعنوان یک نقطه انتهایی API حداقل در میآورید و توکن بازگشتی را به ویجت میدهید. هر دو تنها چند خط کد هستند.
Blazor به شما یک مدل کامپوننت و یک حلقه رندر میدهد که به جاوااسکریپتهای شخص ثالث اهمیتی نمیدهد. Doconut با آن کار میکند نه بر خلاف آن: رندر در سمت سرور در فرآیند خود شما انجام میشود و ویجت در یک عنصر سادهای که از طریق چرخه حیات عادی interop کنترل میکنید، سوار میشود.
مشکل
مسیر سمت کلاینت به معنای ارسال یک موتور رندر به مرورگر است. در Blazor WebAssembly این مستقیماً بر حجم دانلود شما تأثیر میگذارد و فقط PDF را پوشش میدهد — به محض اینکه کسی یک DOCX یا XLSX بارگذاری کند، دوباره به نقطه شروع باز میگردید.
مسیر iframe‑to‑Office به این معنی است که اسناد شما از طریق زیرساخت شخص دیگری عبور میکنند، که این گفتگویی با تیم امنیتی شماست که احتمالاً نمیخواهید دو بار داشته باشید.
Doconut مسیر سوم را انتخاب میکند. فایل توسط سرور خود شما به تصاویر صفحه تبدیل میشود و Blazor فقط باید یک div میزبانی کند. درخت کامپوننت شما هرگز یک نمایشگر که مالک آن نیست را دوباره رندر نمیکند و موتور diff هیچ چیزی برای مقابله ندارد.
قابلیتها
رندر به هر حال سمت سرور است. در Server فراخوانی مستقیم است؛ در WebAssembly فراخوانی open را بهعنوان یک نقطه انتهایی API حداقل در میآورید و توکن بازگشتی را به ویجت میدهید. هر دو تنها چند خط کد هستند.
ویجت را یکبار، پس از اولین رندر، از طریق هوک استاندارد JS interop مقداردهی اولیه کنید. چون Blazor هرگز مالک DOM داخلی نمایشگر نیست، رندرهای بعدی آن را دست نخورده میگذارند.
Interactive Server، Interactive WebAssembly یا Auto. نمایشگر توسط یک توکن نامشخص بهجای وضعیت کامپوننت هدایت میشود، بنابراین تغییر حالت رندر ادغام را تغییر نمیدهد.
همان کامپوننت PDF، DOCX، XLSX، PPTX، DWG، MSG و بقیهٔ فهرست را باز میکند. شما یک صفحه نمایشگر مینویسید، نه یک صفحه برای هر خانوادهٔ فایل.
رابط کاربری ناوبری همراه با ویجت میآید. شما یک نمایشگر را وصل میکنید، نه اینکه یکی را از یک بوم و ورودی شماره صفحه بسازید.
به جز تصاویر صفحه رندر شده، هیچ چیزی به مرورگر جریان نمییابد، که این در WebAssembly بیشتر از آنچه مردم انتظار دارند مهم است — کلاینت در نهایت بهصورت کامل قابل بازرسی است.
ادغام
doconutHost.mount چند خط JavaScript اختصاصی شماست که $('#div_ctlDoc').docViewer({ ... }) را فراخوانی میکند و سپس .View(token). نگه داشتن آن خارج از Blazor عمدی است — DOM ویجت نباید چیزی باشد که رندرر سعی در تطبیق آن داشته باشد.
پلتفرمهای پشتیبانیشده
// Program.cs — order matters
builder.Services.AddDoconut(options =>
{
options.LicensePath = "Doconut.Viewer.lic";
});
builder.Services.AddSession();
app.UseSession(); // before UseDoconut()
app.UseDoconutResources(); // before UseDoconut()
app.UseDoconut();
// Viewer.razor — open server-side, hand the token to the widget
@inject Doconut.Viewer Viewer
@inject IJSRuntime JS
<div id="divDocViewer"><div id="div_ctlDoc"></div></div>
@code {
protected override async Task OnAfterRenderAsync(bool firstRender)
{
if (!firstRender) return;
// Authorize first — the viewer renders whatever you hand it.
string token = await Viewer.OpenDocumentAsync("wwwroot/files/Sample.pdf");
await JS.InvokeVoidAsync("doconutHost.mount", token);
}
}جزئیات
هر دو. رندر همیشه سمت سرور انجام میشود، بنابراین در WebAssembly یک نقطه انتهایی اضافه میکنید که OpenDocumentAsync را فراخوانی کرده و توکن را برمیگرداند. کلاینت هرگز سندی را تجزیه نمیکند، که دقیقاً دلیل این است که بار WASM بدون تغییر میماند.
خیر، به شرطی که در عنصری که Blazor بهعنوان برگ در نظر میگیرد سوار شوید. یک div خالی رندر کنید و اجازه دهید ویجت آن را از طریق interop پر کند — موتور diff فرزندی برای تطبیق ندارد.
خیر. یک صفحه کل فهرست را مدیریت میکند. فرمت از سندی که باز میکنید تشخیص داده میشود، نه از پیش توسط شما انتخاب میشود.
ASP.NET Core
به عنوان DI معمولی بهاضافه میدلور ثبت میشود. احراز هویت، لاگگیری و میزبانی که قبلاً دارید را به ارث میبرد.
ASP.NET Coreرندر PDF سمت سرور به تصاویر صفحه — کاربر سند را میخواند بدون اینکه هرگز فایل را دریافت کند.
PDFیک مجوز موقت چند دقیقه زمان میبرد تا درخواست شود و بهصورت کامل بر روی دستگاه شما اجرا میشود. فایلهایی که مهم هستند، همان فایلهایی هستند که در حال حاضر نمایشگر فعلی شما را خراب میکنند.