نظرات مطالب
معرفی و استفاده از DDL Triggers در SQL Server
با سلام و احترام؛ همانطور که در متن به عرض رسانده شده:
" از عبارت  ON  برای مشخص کردن محدوده Trigger در سطح SQL Instance (در این صورت ON All SERVER نوشته می‌شود) و یا در سطح Database (در این حالت ON DATABASE نوشته می‌شود)  استفاده می‌شود و از عبارت FOR  برای مشخص کردن رویداد یا گروه رویدادی که سبب فراخوانی  Trigger می‌شود، استفاده  خواهد شد.  "
در خصوص مثالی که اشاره کردید، به نظرم می‌رسد از Trigger برای این منظور استفاده نمی‌شود (در حوزه‌ی بکاپ و ریستور)، شاید اگر قصدتان به منظور ثبت log و ... بایست از Auditing استفاده کنید. به این منظور در Auditing با توجه به جدول زیر می‌توان اقدام به ثبت موارد نمود:
Server-Level Audit Action Groups  
Action group name 
 Event Class   Description 
 BACKUP_RESTORE_GROUP   Audit Backup/Restore  
 یک دستور Backup یا Restore صادر شود  
به طور مختصر Auditing به شرح زیر است:
 بررسی SQL Server Audit
 بازبینی (Auditing) شامل پیگیری و ثبت رویدادهایی است که در سطح SQL Instance و یا Database‌های روی یک سیستم اتفاق می‌افتد. چندین سطح برای Auditing در SQL Server وجود دارد که به صلاحدید و نیازمندی‌های نصب شما وابسته است. شما می‌توانید گروه اقدامات بازبینی سرویس دهنده (server audit action groups) را به ازای هر SQL Instance و گروه اقدامات بازبینی بانک اطلاعاتی (database audit action groups) را  به ازای هر بانک اطلاعاتی ثبت کنید. رویداد Audit هر زمان عملی که مورد رسیدگی قرار گرفته اتفاق افتد، رخ می‌دهد.
تا پیش از SQL SERVER 2008، شما باید از خصیصه‌های متعددی برای انجام یک مجموعه کامل بازبینی (Auditing) برای نمونه DDL Trigger، DML Trigger و SQL Trace، بر روی یک SQL Instance استفاده می‌کردید.
SQL SERVER 2008، همه قابلیت‌های Auditing را روی یک audit specification ترکیب می‌کند. Audit Specification با تعریف یک شی بازبینی (audit object) در سطح سرویس دهنده برای ثبت (logging) یک دنباله بازبینی (audit trial) آغاز می‌شود. توجه شود که بایست یک شیء بازبینی ایجاد کنید پیش از اینکه یک Server Audit Specification و یا Database Audit Specification ایجاد کنید.
Server Audit Specification، گروه اقدامات در سطح سرویس دهنده را جمع آوری می‌کند که با رویدادهای وسیعی فعال می‌شوند، این گروه اقدامات تحت عنوان  Server-Level Audit Action Groups تشریح شده اند. شما می‌توانید یک Server Audit Specification را به ازای هر Audit ایجاد کنید چرا که هر دو در محدوده یک SQL Instance ایجاد می‌شوند.
Database Audit Specification، گروه اقدامات در سطح بانک اطلاعاتی را جمع آوری می‌کند که با رویدادهای وسیعی فعال می‌شود. این گروه اقدامات تحت عنوان‌های Database-Level Audit Action Groups و Database-Level Audit Actions تشریح شده اند.می توانید یک Database Audit Specification را به ازای هر Audit در بانک اطلاعاتی SQL Server ایجاد کنید.
همچنین می‌توانید هر گروه اقدامات بازبینی(audit action groups) یا رویدادهای بازبینی(audit events) را به یک Database Audit Specification اضافه کنید. گروه اقدامات بازبینی، گروه اقدامات از پیش تعریف شده ای هستند و رویدادهای بازبینی اقدامات تجزیه ناپذیری هستند که توسط موتور بانک اطلاعاتی مورد رسیدگی قرار می‌گیرند، هر دو در محدوده بانک اطلاعاتی (Database) هستند. این اقدامات برای Audit فرستاده می‌شوند تا در Target (که می‌تواند یک فایل، Windows Security Log و یا Windows Application Log باشد) ذخیره شوند. برای نوشتن در Windows Security Log لازم است که Service Account سرویس دهنده شما به Policy، Generate security audits اضافه شده باشد، به صورت پیش فرض Local System، Local Service و Network Service بخشی از این Policy می‌باشند. پس از اینکه Audit را ایجاد و فعال کردید، Target ورودی‌ها را دریافت خواهد کرد. 
Server-Level Audit Action Groups (گروه اقدامات بازبینی در سطح سرویس دهنده)
این گروه اقدامات به گروه رویداد Security Audit شبیه هستند. به طور خلاصه این گروه اقدامات، اقداماتی را که در یک SQL Instance شامل می‌شوند، در بر می‌گیرد. برای مثال اگر گروه اقدام مناسب با Server Audit Specification اضافه شده باشد هر شیء در هر Schema که مورد دستیابی قرار می‌گیرد، ثبت می‌شود. اقدامات در سطح سرویس دهنده به شما اجازه نمی‌دهد که جزئیات اقدامات در سطح بانک اطلاعاتی را فیلتر کنید. یک بازبینی در سطح بانک اطلاعاتی برای انجام به جزئیات دقیق فیلتر کردن نیاز دارد، برای مثال اجرای دستور Select روی جدول Customers برای login هایی که در گروه Employee هستند.
Database-Level Audit Action Groups (گروه اقدامات بازبینی در سطح بانک اطلاعاتی)
این گروه اعمال به کلاس‌های رویداد Security Audit  شبیه هستند.
Database-Level Audit Actions
اقدامات در سطح بانک اطلاعاتی، اقدامات بازبینی خاصی را به طور مستقیم روی Database، Schema و اشیاء Schema (از قبیل جداول، View ها، رویه‌های ذخیره شده، توابع و ... ) فراهم می‌کند. این اقدامات برای فیلدها (Columns) صدق نمی‌کنند.
Audit-Level Audit Action Groups
شما می‌توانید اقداماتی را که در فرآیند Auditing هستند، بازبینی کنید که می‌تواند در محدوده سرویس دهنده یا بانک اطلاعاتی باشد. در محدوده بانک اطلاعاتی تنها برای database audit specification رخ می‌دهد.
  جهت بررسی بیشتر به این لینک مراجعه شود.
مطالب
کدامیک از بسته‌های NET Core. را باید دریافت کنیم؟
زمانیکه به صفحه‌ی دریافت نگارش‌های مختلف NET Core. مراجعه می‌کنیم، بسته‌های مختلفی از یک نگارش قابل مشاهده هستند و در بدو امر واضح نیست که کدامیک را باید دریافت کرد. در این مطلب تفاوت‌های بین این بسته‌ها را مرور خواهیم کرد.


کدام نگارش‌های NET Core. بر روی سیستم شما نصب هستند؟

پیش از انجام هرکاری نیاز است بررسی کنیم کدامیک از بسته‌های ارائه شده، بر روی سیستم جاری نصب هستند. برای انجام اینکار دستور زیر را در خط فرمان صادر کنید:
 dotnet --info
اگر این دستور کار نکرد و خطایی را دریافت کردید، یعنی NET Core. اصلا بر روی سیستم شما نصب نیست. برنامه dotnet.exe جزئی از runtime نصب شده‌است و به صورت خودکار به path سیستم اضافه می‌شود. به همین جهت است که در صورت نصب آن، فرمان dotnet در هر مسیری قابل اجرا است.
Runtime تنها ویژگی‌های اساسی جهت اجرای برنامه‌های از پیش کامپایل شده‌ی NET Core. را با اجرای فرمانی مانند dotnet mydll.dll و یا اجرای دستور dotnet --info برای دریافت اطلاعاتی از جزئیات این ویژگی‌ها، به همراه دارد. اما برای کار با سورس کدها، build، publish و هر کار دیگری با آن‌ها، حتما باید SDK نیز نصب شود.

خروجی فرمان فوق بر روی سیستم من چنین چیزی است:
 C:\Users\Vahid>dotnet --info
.NET Core SDK (reflecting any global.json):
 Version: 2.1.301
 Commit: 59524873d6

Runtime Environment:
 OS Name:   Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID: win10-x64
 Base Path: C:\Program Files\dotnet\sdk\2.1.301\

Host (useful for support):
  Version: 2.1.1
  Commit:  6985b9f684

.NET Core SDKs installed:
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.301 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
اولین شماره نگارش نمایش داده شده‌ی در این لیست (2.1.301)، شماره نگارش SDK فعال است. سپس شماره نگارش 2.1.1 به معنای شماره نگارش Runtime فعال بر روی سیستم است که هاست dotnet.exe به شمار می‌رود. سپس لیست SDKها و Runtimeهای نصب شده‌ی بر روی سیستم را نمایش می‌دهد.
باید دقت داشت که بر روی یک سیستم می‌توان چندین SDK و چندین Runtime مختلف را نصب کرد و هر پروژه از شماره نگارش خاصی استفاده کند. شماره نگارش runtime استفاده شده‌ی در پروژه‌ها در فایل csproj، توسط مدخل زیر مشخص می‌شود:
 <TargetFramework>netcoreapp2.1</TargetFramework>
در مورد SDK اینطور نیست و همواره از آخرین SDK نصب شده (همان شماره نگارش SDK فعال فوق) استفاده می‌شود، مگر اینکه فایل ویژه‌ای به نام global.json را در ریشه‌ی اصلی solution قرار دهید؛ با این محتوای فرضی:
 {
  "sdk": {
        "version": "2.1.300-rc.31211"
  }
}
در این حالت پروژه‌ی جاری را وادار می‌کنید بجای استفاده‌ی از آخرین SDK نصب شده‌ی بر روی سیستم، از نگارش SDK خاصی استفاده کند.
البته در اکثر موارد نیازی به انجام این کار نیست؛ چون SDK، با تمام نگارش‌های قبلی سازگار است و همواره استفاده‌ی از آخرین SDK نصب شده توصیه می‌شود. به همین جهت فایل global.json را پس از ایجاد یک solution جدید مشاهده نمی‌کنید؛ مگر اینکه خودتان به دلایل خاصی آن‌را اضافه و مقید نمائید.


تفاوت بسته‌های مختلف قابل دریافت NET Core. در چیست؟

زمانیکه برای دریافت آخرین نگارش NET Core. به سایت آن مراجعه می‌کنیم، به ازای هر نگارش، یک چنین لیستی قابل مشاهده است:
• .NET Core Runtime
• .NET Core SDK
• .NET Core Hosting Bundle
• Visual Studio
• ASP.NET Core Installer
و اکنون سؤالی که مطرح می‌شود این است: کدامیک را باید دریافت کرد؟

Visual Studio

اگر کاربر ویندوز هستید، با نصب آخرین نگارش Visual Studio، می‌توانید به همراه آن، آخرین نگارش SDK ،runtime و اجزای هاست برنامه‌های ASP.NET Core بر روی IIS را نیز بر روی سیستم خود نصب کنید.


NET Core SDK.

هدف از ارائه‌ی بسته‌ی SDK، انجام فرآیندهای build‌، اجرا و مدیریت امور مرتبط با NET Core.، بدون استفاده از Visual Studio و بر روی تمام سیستم عامل‌های پشتیبانی شده‌است. زمانیکه یک بسته‌ی SDK را نصب می‌کنید، به همراه آن این موارد نیز نصب می‌شوند:
• .NET Core SDK 
• .NET Core Runtime 
• ASP.NET Core Runtime
به همین جهت حجم آن از بسته‌ی تکی runtime بیشتر است و با نصب آن دیگر نیازی به دریافت مجزای بسته‌های runtime نیست.

بنابراین دلیل نصب آن می‌تواند شامل یکی از موارد زیر باشد:
 - بر روی سیستمی که در حال توسعه‌ی برنامه‌های مبتنی بر NET Core. هستید. این تمام چیزی است که به آن نیاز دارید.
 - بر روی سروری که نیاز است دستور dotnet را برای انجام فرآیندهای build/publish اجرا کند.


NET Core Runtime.

بسته‌های Runtimes، کوچکترین بسته‌ی ممکن در این لیست هستند و هدف از آن‌ها صرفا اجرای برنامه‌های کامپایل شده‌ی NET Core. در سکوهای کاری مختلف پشتیبانی شده‌ی توسط آن است.
باید دقت داشت که اگر برنامه‌ی شما از «ASP.NET Core meta package» استفاده می‌کند، این بسته در runtime لحاظ نشده‌است و در یک چنین حالتی باید بسته‌ی ASP.NET Core را به صورت جداگانه دریافت و نصب کنید. هرچند اگر از این متاپکیج‌ها استفاده نکنید و بسته‌های مورد نیاز را به صورت مستقیم به برنامه‌ی خود اضافه کنید، این بسته‌ها جزئی از فایل‌های publish نهایی بوده و در این حالت برنامه توسط بسته‌ی runtime نیز قابل اجرا است.
در این حالت برنامه‌ی dotnet بجز اجرای برنامه‌ها و ارائه‌ی اطلاعاتی در مورد خود آن، کارهای دیگری را مانند build و یا publish، نمی‌تواند انجام دهد و برنامه در این حالت باید کاملا از پیش کامپایل شده باشد.

بنابراین دلیل نصب آن می‌تواند شامل یکی از موارد زیر باشد:
- برای اجرای برنامه‌های از پیش کامپایل شده‌ای که به همراه تمام وابستگی‌های مورد نیاز هم هستند.
- برای اجرای برنامه‌های وبی که از ASP.NET Meta packages استفاده نمی‌کنند


ASP.NET Core Installer

همانطور که در توضیحات بسته‌ی runtime عنوان شد، این بسته، متاپکیج‌های ASP.NET Core را به همراه ندارد. اگر به آن‌ها نیاز دارید، باید آن‌ها را به صورت جداگانه توسط ASP.NET Core installer نصب کنید که شامل این موارد است:
- The ASP.NET Runtime Meta Packages
- Microsoft.AspNetCore.App
- Microsoft.AspNetCore.All
 
NET Core Windows Hosting Pack.

نصب این بسته برای هاست برنامه‌های ASP.NET Core در ویندوز و بر روی IIS ضروری است و شامل این اجزا می‌شود:
- 32 bit and 64 .NET Core Runtimes
- ASP.NET Runtime Packages (Microsoft.AspNetCode.App/All)
- IIS Hosting Components
بنابراین این بسته شامل تمام موارد یاد شده‌است منهای قابلیت‌های SDK برای build و publish برنامه‌ها.



بنابراین به صورت خلاصه

برای سرورها این موارد را نصب کنید:
- در ویندوز: Windows Server Hosting Bundle
- برای Mac و لینوکس:  .NET Core Runtime + ASP.NET Core Runtimes

برای سیستم توسعه‌ی شخصی این موارد را نصب کنید:
- SDK
- اگر از ویندوز استفاده می‌کنید: Visual Studio هم به همراه SDK نصب می‌شود.

برای اجرای برنامه‌های از پیش کامپایل شده که به همراه تمام وابستگی‌های مورد نیاز هم هستند:
- تنها Runtime را نصب کنید.
اگر این برنامه‌ی از پیش کامپایل شده از ASP.NET Runtime Meta packages استفاده می‌کند:
- ASP.NET Runtimes را نیز نصب کنید.
پاسخ به بازخورد‌های پروژه‌ها
گرفتن گزارش از کلیه گریدهای موجود در صفحه
سلام؛ خیر. علت این است که برای تهیه یک گزارش شما نیاز دارید تمام مباحث صفحه بندی، تنظیمات ستون‌ها، قلم، منبع داده و غیره رو پیاده سازی کنید. تمام این‌ها هم به یک منبع داده متصل می‌شود. در اینجا ستون‌ها متناظر است با یک منبع داده.

البته این رو اضافه کنم که امکان merge کردن چند فایل pdf با هم در iTextSharp وجود دارد. یعنی می‌تونید چند گزارش کاملا مستقل رو با PdfReport ایجاد کنید. هر کدام به صورت مستقل یک فایل pdf به شما می‌دهند. بعد این‌ها رو با استفاده از iTextSharp یکی کنید. نحوه کار رو می‌تونید در این پروژه سورس باز PDF Merge ملاحظه کنید.
اشتراک‌ها
انتقال مخازن از Bitbucket به GitHub

سایت بیت باکت یکی از سایت‌های مخزن گیت رایگان است که تا 5 نفر قادر هستید به صورت خصوصی از آن بهره برد اما در سایت گیت‌هاب این قابلیت برای شما به صورت پیشفرض فعال نبوده و لازم است هزینه‌ای پرداخت شود جهت مدیریت پروژه به صورت خصوصی. 

انتقال مخازن از Bitbucket به GitHub
اشتراک‌ها
ترجمه کتاب Learning Ionic به زبان فارسی

ترجمه کتاب Learning Ionic به زبان فارسی برای اولین بار (تنها مرجع فارسی)

 یاد بگیرید که چگونه می‌توان با تکنولوژی‌های سمت کاربر وب برنامه‌های موبایل برای تمام پلتفرم‌های موجود بسازید.

برای دانلود و همکاری در ترجمه به مخزن کد پروژه مراجعه کنید.

 

ترجمه کتاب Learning Ionic به زبان فارسی
نظرات مطالب
معرفی کتابخانه Postal برای ASP.NET MVC
ممنون از مقالتون
من توی ارسال به شیوه strongly type مشکل دارم. خطای زیر رو میده:
A from address must be specified
توی مخزن خود پروژه توی گیت هاب هم بررسی کردم جوابی نیافتم.
پاسخ به بازخورد‌های پروژه‌ها
پکیج های ناهماهنگ بعد از restore
جهت اطلاع
تمام وابستگی‌های back-end این پروژه به آخرین نگارش‌های آن‌ها به روز و به صورت یک pull request جدید ارسال شدند.
می‌توانید این مخزن کد را در حالت pull request ارسالی، از اینجا برای آزمایش، پیش از یکی‌سازی نهایی دریافت کنید.
پروژه‌ها
فروشگاه اینترنتی (الکترونیک) با معماری سه لایه
دانلود پروژه فروشگاه اینترنتی با معماری سه لایه

این پروژه به کمک امکانات شیرین C#‎.NET, ASP.NET,jQuery در محیط Visual Studio 2010 طراحی و پیاده سازی شده است.
ممکن است در این برنامه به اشکالاتی برخورد کنید چون یک پروژه کاری بوده که در طی یک کلاس درس تکمیل شده و هم اکنون در اختیار شما قرار می‌گیرد لطفا در صورت بروز مشکل از طریق بازخورد مطرح فرمایید و از ارسال پیام خصوصی خودداری نمایید.
پروژه با معماری سه لایه طراحی و پیاده سازی شده است
 که شامل لایه DAL برای ارتباط با بانک
 BLL برای اعمال قوانین تجاری
و لایه نمایش آن که ASP.NET استفاده شده است
 بانک اطلاعاتی برنامه با SQL SERVER 2008 می‌باشد که می‌توانید آن را تغییر داده و از بانک اطلاعاتی دلخواه خود استفاده کنید.
فایل اسکریپت نیز در کنار پروژه برای نسخه‌های دیگر SQL قرار گرفته است.
 لازم به ذکر است که برنامه ProviderBase نیز می‌باشد.
یعنی شما میتوانید بانک دلخواه خود را استفاده نموده و بدون کوچکترین تغییری در برنامه سایت از آن استفاده نمایید فقط کافی است که در فایل web.config مشخصات آن Provider را ثبت نموده و کدهای مربوط به Provider خود را بنویسید.
برای استفاده ابتدا دیتابیس را در SQL خود Attach کرده و در فایل web.config در قسمت تنظیمات ConnectionString تنظیمات سرور و نام دیتابیس را وارد نمایید.

این پروژه دارای امکانات
  • فروشگاه اینترنتی با قابلیت گروه بندی محصولات
  • ذخیره تصاویر در دیتابیس و بازیابی با یک Handler
  • سرویس اعلانات سایت
  • درج کلمات کلیدی هر صفحه به صورت اتوماتیک و با توجه به محتوای صفحه
  • استفاده از قابلیت Profile برای کاربران
  • کارت خرید و ذخیره آن در پروفایل کاربر
  • ثبت سوابق خرید کاربر
  • ثبت فیش‌های پرداختی کاربر
  • ثبت نام کاربران جدید در سایت
  • ثبت، نمایش و مدیریت سخنان قصار در نرم افزار
  • امکان Cache کردن اطلاعات دریافتی از بانک و مدیریت Cache 
  • پیاده سازی تمامی کویری‌های بان با Store Procedure در SQL Server
  • استفاده از سرویس Membership
  • خواندن تنظیمات برنامه از فایل Web.Config و معادل‌سازی آن با کلاس‌های مربوطه
  • و ...
البته شاید کامل نباشد اما به عنوان یک منبع آموزشی در زمینه برنامه نویسی سه لایه و بعضی ایده‌های خاص ممکن است برای دوستان مبتدی و متوسطه در زمینه طراحی سایت مفید واقع شود.
در صورت لزوم می‌توانید به لینک اصلی این پروژه در آدرس سایت ما مراجعه نمایید.
نام کاربری و کلمه عبور مدیریت سایت:
UserName: Admin
Password: 1234567@
----------
UserName: Saber_Fatholahi
Password: 1234567@

مطالب
تهیه آزمون واحد جهت کار با محتوای فایل‌ها

یکی از شروط تهیه‌ آزمون‌های واحد، خارج نشدن از مرزهای سیستم در حین بررسی آزمون‌های مورد نظر است؛ تا بتوان تمام آزمون‌ها را با سرعت بسیار بالایی، بدون نگرانی از در دسترس نبودن منابع خارجی، درست در لحظه انجام آزمون‌ها، به پایان رساند. اگر این خروج صورت گیرد، بجای unit tests با integration tests سر و کار خواهیم داشت. در این میان، کار با فایل‌ها نیز مصداق بارز خروج از مرزهای سیستم است.
برای حل این مشکل راه حل‌های زیادی توصیه شده‌اند؛ منجمله تهیه یک اینترفیس محصور کننده فضای نام System.IO و سپس استفاده از فریم ورک‌های mocking و امثال آن. یک نمونه از پیاده سازی آن‌را اینجا می‌توانید پیدا کنید : (+)
اما راه حل ساده‌تری نیز برای این مساله وجود دارد و آن هم افزودن فایل‌های مورد نظر به پروژه آزمون واحد جاری و سپس مراجعه به خواص فایل‌ها و تغییر Build Action آن‌‌ها به Embedded Resource می‌باشد. به این صورت پس از کامپایل پروژه، فایلهای ما در قسمت منابع اسمبلی جاری قرار گرفته و به کمک متد زیر قابل دسترسی خواهند بود:
using System.IO;
using System.Reflection;

public class UtHelper
{
public static string GetInputFile(string filename)
{
var thisAssembly = Assembly.GetExecutingAssembly();
var stream = thisAssembly.GetManifestResourceStream(filename);
return new StreamReader(stream).ReadToEnd();
}
}

نکته‌ای را که اینجا باید به آن دقت داشت، filename متد GetInputFile است. چون این فایل دیگر به صورت متداول از فایل سیستم خوانده نخواهد شد، نام واقعی آن به صورت namespace.filename می‌باشد (همان نام منبع اسمبلی جاری).
اگر جهت یافتن این نام با مشکل مواجه شدید، تنها کافی است اسمبلی آزمون واحد را با برنامه Reflector یا ابزارهای مشابه گشوده و نام منابع آن‌را بررسی کنید.