نظرات مطالب
هزینه استفاده از دات نت فریم ورک چقدر است؟
- من نمی‌دونم محدود بودن تعداد breakpoints چه اهمیتی داره، یا اینکه چندتا مثلا شما رو راضی می‌کنه. یا اینکه مثلا کامپایلر CPP‌ چه ربطی به بحث دات نت داره. خوشبختانه پروژه سورس باز CodeBlocks موجود است و کامپایلر GCC لینوکس رو در ویندوز به صورت یکپارچه به شما ارائه می‌ده (http://www.codeblocks.org/). بحث ما اینجا در مورد دات نت است در مورد کدهای مدیریت شده آن.
- من در مورد مایکروسافت عرض کردم نه در مورد ناول. در مورد قراردادهای مایکروسافت با ناول و پشتیبانی مایکروسافت از ناول. در مورد استفاده کنندگان از مونو مراجعه کنید به کامنت‌های لینکی که در مورد شرکت زاماریان داده شد. لینکش در متن فوق هست.
- به این اصطلاحا می‌گن توهم توطئه ... (+)
و صد البته اگر در رابطه با کاهش هزینه‌های توسعه با دات نت باشد بسیار نیکو و پسندیده است و در راستای بحث جاری. اون شرکت معروف سان هم اگر کارش درست بود الان سرپا بود. هنوز نتونسته جاوای 7 رو جمع کنه. سیستم JIT اون باگ داره. کسی جرات نمی‌کنه ازش در محیط توسعه استفاده کنه : (+)

من فقط خواستم ثابت کنم با حداقل هزینه و با یک مجوز اولیه ویندوز راحت می‌شود با دات نت برنامه توسعه داد. هزینه زیادی هم ندارد. لطفا بحث رو به حاشیه نکشید.
نظرات مطالب
هزینه استفاده از دات نت فریم ورک چقدر است؟
- من نمی‌دونم محدود بودن تعداد breakpoints چه اهمیتی داره، یا اینکه چندتا مثلا شما رو راضی می‌کنه. یا اینکه مثلا کامپایلر CPP‌ چه ربطی به بحث دات نت داره. خوشبختانه پروژه سورس باز CodeBlocks موجود است و کامپایلر GCC لینوکس رو در ویندوز به صورت یکپارچه به شما ارائه می‌ده (http://www.codeblocks.org/). بحث ما اینجا در مورد دات نت است در مورد کدهای مدیریت شده آن.
- من در مورد مایکروسافت عرض کردم نه در مورد ناول. در مورد قراردادهای مایکروسافت با ناول و پشتیبانی مایکروسافت از ناول. در مورد استفاده کنندگان از مونو مراجعه کنید به کامنت‌های لینکی که در مورد شرکت زاماریان داده شد. لینکش در متن فوق هست.
- به این اصطلاحا می‌گن توهم توطئه ... (+)
و صد البته اگر در رابطه با کاهش هزینه‌های توسعه با دات نت باشد بسیار نیکو و پسندیده است و در راستای بحث جاری. اون شرکت معروف سان هم اگر کارش درست بود الان سرپا بود. هنوز نتونسته جاوای 7 رو جمع کنه. سیستم JIT اون باگ داره. کسی جرات نمی‌کنه ازش در محیط توسعه استفاده کنه : (+)

من فقط خواستم ثابت کنم با حداقل هزینه و با یک مجوز اولیه ویندوز راحت می‌شود با دات نت برنامه توسعه داد. هزینه زیادی هم ندارد. لطفا بحث رو به حاشیه نکشید.
مطالب
React 16x - قسمت 2 - بررسی پیشنیازهای جاوا اسکریپتی - بخش 1
برای کار با React، نیاز است با ES6 آشنایی داشته باشید که در این سایت، یک سری کامل بررسی مقدمات آن‌را پیشتر مرور کرده‌ایم. علاوه بر توصیه‌ی مطالعه‌ی این سری (اینکار الزامی است)، در این قسمت خلاصه‌ی بسیار سریع و کاربردی آن‌را که بیشتر در برنامه‌های مبتنی بر React مورد استفاده قرار می‌گیرند، با هم مرور خواهیم کرد. در قسمت‌های بعدی، اهمیت ذکر این خلاصه بیشتر مشخص می‌شود.

برای بررسی ویژگی‌های جاوا اسکریپت مدرن، یک پروژه‌ی جدید React را ایجاد می‌کنیم.
> create-react-app sample-02
> cd sample-02
> npm start
سپس تمام کدهای داخل index.js را نیز حذف می‌کنیم. اکنون تمام کدهای خالص جاوا اسکریپتی خود را داخل این فایل خواهیم نوشت.
به علاوه چون در این قسمت خروجی UI نخواهیم داشت، تمام خروجی را در کنسول developer tools مرورگر خود می‌توانید مشاهده کنید (فشردن دکمه‌ی F12).


var، let و const

در اکثر زبان‌های برنامه نویسی، متغیرها در محدوده‌ی دید قطعه کدی که تعریف شده‌اند (scope)، قابل دسترسی هستند. برای نمونه محتوای فایل index.js پروژه را به صورت زیر تغییر داده و با فرض اجرای دستور npm start، خروجی آن‌را می‌توان در کنسول مرورگر مشاهده کرد.
function sayHello() {
  for (var i = 0; i < 5; i++) {
    console.log(i);
  }
  console.log(i);
}

sayHello();
در این مثال متغیر i، مخصوص قطعه کد حلقه، تعریف شده‌است. بنابراین به ظاهر نباید خارج از این حلقه نیز قابل دسترسی باشد. اما خروجی آن به صورت زیر است:


در آخرین پیمایش حلقه، i مساوی 5 شده و از حلقه خارج می‌شود. اما چون در اینجا برای تعریف متغیر از واژه‌ی کلیدی var استفاده شده‌است، محدوده‌ی دید آن به کل تابعی که در آن تعریف شده‌است، بسط پیدا می‌کند. به همین جهت در این خروجی، عدد 5 را نیز مشاهده می‌کند که حاصل دسترسی به i، خارج از حلقه‌است.
برای یک دست سازی این رفتار با سایر زبان‌های برنامه نویسی، در ES6، واژه‌ی کلیدی جدیدی به نام let تعریف شده‌است که میدان دید متغیر را به قطعه کدی که در آن تعریف شده‌است، محدود می‌کند. اکنون اگر در حلقه‌ی فوق بجای var از let استفاده شود، یک چنین خطایی در مرورگر ظاهر خواهد شد که عنوان می‌کند، i استفاده شده‌ی در خارج از حلقه، تعریف نشده‌است.
./src/index.js
  Line 14:15:  'i' is not defined  no-undef

Search for the keywords to learn more about each error.

علاوه بر let، واژه‌ی کلیدی جدید const نیز به ES6 اضافه شده‌است که از آن برای تعریف ثوابت استفاده می‌شود. constها نیز همانند let، میدان دید محدود شده‌ای به قطعه کد تعریف شده‌ی در آن دارند؛ اما قابلیت انتساب مجدد را ندارند:
 const x = 1;
x = 2; // Attempting to override 'x' which is a constant.
اگر یک چنین قطعه کدی را اجرا کنیم، خطای x is const را در مرورگر می‌توان مشاهده کرد.

به صورت خلاصه از این پس واژه‌ی کلیدی var را فراموش کنید. همیشه با const جهت تعریف متغیرها شروع کنید. اگر به خطا برخوردید و نیاز به انتساب مجدد وجود داشت، آن‌را به let تغییر دهید. بنابراین استفاده از const همیشه نسبت به let ارجحیت دارد.


اشیاء در جاوا اسکریپت

اشیاء در جاوا اسکریپت به صورت مجموعه‌ای از key/value‌ها تعریف می‌شوند:
const person = {
  name: "User 1",
  walk: function() {}, // method
  talk() {} // concise method
};
در اینجا امکان تعریف یک تابع نیز وجود دارد که چون درون یک شیء قرار می‌گیرد، اینبار «متد» نامیده می‌شود. همچنین در ES6 می‌توان این متدها را به صورت معمولی، مانند متد talk نیز تعریف کرد که به آن‌ها concise method می‌گویند. بنابراین نحوه‌ی تعریف فوق را به نحو زیر نیز می‌توان خلاصه کرد:
const person = {
  name: "User 1",
  walk() {},
  talk() {}
};
پس از تعریف این شیء، روش دسترسی به اجزای آن به صورت زیر است:
person.talk();
person.name = "User 3";
person["name"] = "User 2";
به دو مورد اول، روش dot notation می‌گویند که از همان ابتدا دقیقا مشخص است کدامیک از خواص و متدهای شیء تعریف شده، مورد استفاده قرار می‌گیرند.
مورد آخر همان روش استفاده از key/valueها است که اساس اشیاء جاوا اسکریپتی را تشکیل می‌دهد. البته از این روش فقط زمانی استفاده کنید که قرار است یکسری کار پویا صورت گیرند (مقدار key به صورت متغیر دریافت شود) و از ابتدا مشخص نیست که کدام خاصیت یا متد قرار است تعریف و استفاده شود:
const targetMember = "name";
person[targetMember] = "User 2";


واژه‌ی کلیدی this در جاوا اسکریپت

از واژه‌ی کلیدی this، در قسمت‌های بعدی زیاد استفاده خواهیم کرد. به همین جهت نیاز است تفاوت‌های اساسی آن‌را با سایر زبان‌های برنامه نویسی بررسی کنیم.
همان شیء person را که پیشتر تعریف کردیم درنظر بگیرید. در متد walk آن، مقدار this را لاگ می‌کنیم:
const person = {
  name: "User 1",
  walk() {
    console.log(this);
  },
  talk() {}
};

person.walk();
خروجی این قطعه، به صورت زیر است:


شیء this در جاوا اسکریپت، همانند سایر زبان‌های برنامه نویسی مانند سی‌شارپ و یا جاوا رفتار نمی‌کند. در سایر زبان‌های نامبرده شده، this همواره ارجاعی را به وهله‌ای از شیء جاری، باز می‌گرداند؛ دقیقا همانند تصویری که در بالا مشاهده می‌کنید. در اینجا نیز this جاوا اسکریپتی لاگ شده، ارجاعی را به وهله‌ی جاری شیء person، بازگشت داده‌است. اما مشکل اینجا است که this در جاوا اسکریپت، همیشه به این صورت رفتار نمی‌کند!
برای نمونه در ادامه یک ثابت را به نام walk تعریف کرده و آن‌را به person.walk مقدار دهی می‌کنیم:
const walk = person.walk;
console.log(walk);
دقت داشته باشید که در اینجا از () استفاده نشده‌است (متد walk اجرا نشده‌است). یعنی صرفا «ارجاعی» از متد walk شیء person را به ثابت walk نسبت داده‌ایم. بنابراین اکنون ثابت walk نیز یک function است که حاصل console.log آن به صورت زیر است:


سؤال: اکنون اگر این function را با فراخوانی ()walk اجرا کنیم، چه خروجی را می‌توان مشاهده کرد؟


اینبار this لاگ شده، به شیء person اشاره نمی‌کند و شیء استاندارد window مرورگر را بازگشت داده‌است!
اگر یک function به صورت متدی از یک شیء فراخوانی شود، مقدار this همواره اشاره‌گری به وهله‌ای از آن شیء خواهد بود. اما اگر این تابع به صورت متکی به خود و به صورت یک function و نه متد یک شیء، فراخوانی شود، اینبار this، شیء سراسری جاوا اسکریپت یا همان شیء window را بازگشت می‌دهد.

یک نکته: اگر strict mode جاوا اسکریپت را در پروژه‌ی جاری فعال کنیم، بجای شیء window، مقدار undefined را در خروجی فوق شاهد خواهیم بود.


اتصال مجدد this به شیء اصلی در جاوا اسکریپت

تا اینجا دریافتیم که اگر یک function را به صورت متکی به خود و نه جزئی از یک شیء فراخوانی کنیم، شیء this در این حالت به شیء window سراسری مرورگر اشاره می‌کند و اگر strict mode فعال باشد، فقط undefined را بازگشت می‌هد. اکنون می‌خواهیم بررسی کنیم که چگونه می‌توان این مشکل را برطرف کرد؛ یعنی صرف‌نظر از نحوه‌ی فراخوانی متدها یا تابع‌ها، this همواره ارجاعی را به شیء person بازگشت دهد.
در جاوا اسکریپت، تابع‌ها نیز شیء هستند. برای مثال person.walk نوشته شده نیز یک شیء است. برای اثبات ساده‌ی آن فقط یک دات را پس از person.walk قرار دهید:


همانطور که مشاهده می‌کنید، شیء person.walk مانند تمام اشیاء دیگر جاوا اسکریپت، به همراه متد bind نیز هست. کار آن، انقیاد یک تابع، به یک شیء است. یعنی هرچیزی را که به عنوان آرگومان آن، به آن ارسال کنیم، به عنوان مقدار شیء this درنظر می‌گیرد:
const walk2 = person.walk.bind(person);
console.log(walk2);
walk2();
در اینجا متد bind، یک وهله‌ی جدید از person.walk را بازگشت می‌دهد که در آن شیء person را به عنوان شیء this، تنظیم کرده‌است. به همین جهت اینبار فراخوانی walk2 که به شیء person متصل شده‌است، به this صحیحی بجای window سراسری اشاره می‌کند. از این روش در برنامه‌های مبتنی بر React زیاد استفاده می‌شود.


Arrow functions

تابع زیر را درنظر بگیرید که به یک ثابت انتساب داده شده‌است:
const square = function(number) {
  return number * number;
};
در ES6، روش ساده‌تر و تمیزتری برای این نوع تعاریف، ذیل ویژگی جدید Arrow functions اضافه شده‌است. برای تبدیل قطعه کد فوق به یک arrow function، ابتدا واژه‌ی کلیدی function را حذف می‌کنیم. سپس بین پارامتر تابع و {}، یک علامت <= (که به آن fat arrow هم می‌گویند!) قرار می‌دهیم:
const square2 = (number) => {
  return number * number;
};
اگر مانند اینجا تنها یک تک پارامتر وجود داشته باشد، می‌توان پرانتزهای ذکر شده را نیز حذف کرد:
const square2 = number => {
  return number * number;
};
و اگر این متد پارامتری نداشت، از () استفاده می‌شود.
در ادامه اگر بدنه‌ی این تابع، فقط حاوی یک return بود، می‌توان آن‌را به صورت زیر نیز خلاصه کرد (در اینجا {} به همراه واژه‌ی کلیدی return حذف می‌شوند):
const square3 = number => number * number;
console.log(square3(5));
این یک سطر ساده شده، دقیقا معادل اولین const square ای است که نوشتیم. نحوه‌ی فراخوانی آن نیز مانند قبل است.

اکنون مثال مفید دیگری را در مورد Arrow functions بررسی می‌کنیم که بیشتر شبیه به عبارات LINQ در #C است:
const jobs = [
  { id: 1, isActive: true },
  { id: 2, isActive: true },
  { id: 3, isActive: true },
  { id: 4, isActive: true },
  { id: 5, isActive: false }
];
در اینجا آرایه‌ای از اشیاء job را مشاهده می‌کنید که مورد آخر آن، فعال نیست. اکنون می‌خواهیم لیست کارهای فعال را گزارشگیری کنیم:
var activeJobs = jobs.filter(function(job) {
  return job.isActive;
});
متد filter در جاوا اسکریپت، بر روی تک تک عناصر آرایه‌ی jobs حرکت می‌کند. سپس هر job را به پارامتر متد ارسالی آن که predicate نام دارد، جهت دریافت یک خروجی true و یا false، ارائه می‌دهد. اگر خروجی این متد true باشد، آن job انتخاب خواهد شد و در لیست نهایی گزارش، ظاهر می‌شود.
در ادامه می‌توان این تابع را توسط arrow functions به صورت ساده‌تر زیر نیز نوشت:
var activeJobs2 = jobs.filter(job => job.isActive);
ابتدا واژه‌ی کلیدی function را حذف می‌کنیم. سپس چون یک تک پارامتر را دریافت می‌کند، نیازی به ذکر پرانتزهای آن نیز نیست. در ادامه چون یک تک return را داریم، { return }  را با یک <= جایگزین خواهیم کرد. در اینجا نیازی به ذکر سمی‌کالن انتهای return هم نیست. نوشتن یک چنین کدی تمیزتر و خواندن آن، ساده‌تر است.


ارتباط بین arrow functions و شیء this

نکته‌ی مهمی را که باید در مورد arrow functions دانست این است که شیء this را rebind نمی‌کنند (rebind: مقدار دهی مجدد؛ ریست کردن).
در مثال زیر، ابتدا شیء user با متد talk که در آن شیء this، لاگ شده، ایجاد شده و سپس این متد فراخوانی گردیده‌است:
const user = {
  name: "User 1",
  talk() {
    console.log(this);
  }
};
user.talk();
همانطور که انتظار می‌رود، this ای که در اینجا لاگ می‌شود، دقیقا ارجاعی را به وهله‌ی جاری شیء user دارد.
اکنون اگر متد لاگ کردن را داخل یک تایمر قرار دهیم چه اتفاقی رخ می‌دهد؟
const user = {
  name: "User 1",
  talk() {
    setTimeout(function() {
      console.log(this);
    }, 1000);
  }
};
user.talk();
متد setTimeout، متدی را که به عنوان آرگومان اول آن دریافت کرده، پس از 1 ثانیه اجرا می‌کند.
در این حالت خروجی console.log، مجددا همان شیء سراسری window مرورگر است و دیگر به وهله‌ی جاری شیء user اشاره نمی‌کند. علت اینجا است که پارامتر اول متد setTimeout که یک callback function نام دارد، جزئی از هیچ شیءای نیست. بنابراین دیگر مانند فراخوانی متد ()user.talk در مثال قبلی کار نمی‌کند؛ چون متکی به خود است. هر زمان که یک متد متکی به خود غیر وابسته‌ی به یک شیء را اجرا کنیم، به صورت پیش‌فرض this آن، به شیء window مرورگر اشاره می‌کند.

سؤال: چگونه می‌توان درون یک callback function متکی به خود، به this همان شیء user جاری دسترسی یافت؟
یک روش حل این مساله، ذخیره this شیء user در یک متغیر و سپس ارسال آن به متد متکی به خود setTimeout است:
const user2 = {
  name: "User 2",
  talk() {
    var self = this;
    setTimeout(function() {
      console.log(self);
    }, 1000);
  }
};
user2.talk();
این روشی است که سال‌ها است وجود دارد؛ با ارائه‌ی arrow functions، دیگر نیازی به اینکار نیست و می‌توان از روش زیر استفاده کرد:
const user3 = {
  name: "User 3",
  talk() {
    setTimeout(() => console.log(this), 1000);
  }
};
user3.talk();
در اینجا callback function را تبدیل به یک arrow function کرده‌ایم و چون arrow functions شیء this را rebind نمی‌کنند، یعنی شیء this را به ارث می‌برند. بنابراین console.log مثال فوق، دقیقا به this شیء user اشاره می‌کند و دوباره آن‌را مقدار دهی مجدد نمی‌کند و از همان نمونه‌ی موجود قطعه کد تعریف شده، استفاده خواهد کرد.


کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: sample-02.zip

در قسمت بعد نیز بررسی پیشنیازهای جاوا اسکریپتی شروع به کار با React را ادامه خواهیم داد.
مطالب
تولید خودکار آزمون‌های واحد NUnit

تعدادی ابزار برای تولید خودکار متدهای آزمون‌های واحد NUnit از روی کلاس‌های موجود در یک اسمبلی وجود دارند که به دو دسته تقسیم می‌شود:

الف) آن‌هایی که فقط نام کلاس‌های آزمون واحد و نام متدهای آن‌را به صورت خودکار تولید می‌کنند


این ابزارها و کتابخانه‌ها، تنها کاری که انجام می‌دهند یافتن کلاس‌ها و متدهای عمومی موجود در یک اسمبلی توسط Reflection و سپس تولید یک سری فایل‌ آماده از روی این اطلاعات است. برای مثال اگر نام کلاس شما Class1 است فایلی به نام TestClass1 را تولید می‌کنند و اگر یکی از متد‌های عمومی این کلاس به نام Method1 باشد، یک متد خالی را به نام Method1Test ایجاد خواهند کرد و همین.
تبدیل CodeSmith NUnit Test Generator فوق به یک T4 template کار ساده‌ای است.

ب) ابزارهایی که علاوه بر مورد الف، سعی می‌کنند بدنه‌ای را نیز برای متدهای واحد تولید شده تهیه کنند


این افزونه‌ها و برنامه‌ها سعی می‌کنند به کمک Reflection و همچنین امکانات تولید کد موجود در VS.NET نسبت به تولید کلاس‌ها، متدها و بدنه‌های نمونه آن‌ها اقدام کنند. برای مثال اگر نام متد کلاسی، Method1 به همراه یک پارامتر از نوع int باشد، بدنه تولید شده به همراه وهله سازی از کلاس آن و فراخوانی این متد به همراه پارامتر آن خواهد بود.
مشکل مهم این پروژه‌های سورس باز کوچک هم عدم تعهد به نگهداری آن‌ها است. برای مثال آخرین به روز رسانی موجود افزونه‌ی NUnitGen شرکت ناول، مخصوص VS2008 است یا آخرین به روز رسانی TestGen.Net مربوط به دات نت یک است (سورسی هم که در سایت سورس فورج قرار داده ناقص است) یا مقاله‌ی سایت CodeProject‌ که ذکر گردید، با نگارش‌های جدید NUnit درست کار نمی‌کند و کامپایل نمی‌شود.

در بین این‌ها به نظر من Edwinyeah TestGen.Net کار جالبی را انجام داده است و چندین زبان را هم پشتیبانی می‌کند. البته همانطور که عنوان شد توانایی بارگذاری اسمبلی‌های نگارش‌های جدید دات نت را ندارد که موضوع مهمی نیست. سورس آن‌را می‌توان دریافت و سپس جهت دات نت 4 کامپایل کرد. البته یک سری از کلاس‌های آن هم که در سورس موجود نیستند را می‌شود از اسمبلی کامپایل شده‌ی آن با Reflector درآورد، به پروژه اصلی اضافه و سپس کامپایل کرد!
کامپایل شده‌ی آن‌را جهت دات نت 4 از اینجا دریافت کنید.

اشتراک‌ها
ده اشتباه امنیتی رایج در Sharepoint
اعتماد کامل به تنظیمات امنیتی پیش فرض شیرپوینت خیلی از مواقع میتواند باعث بروز مشکلات امنیتی فراوانی برای ما بشود و اجرای پروژه را در معرض خطر قرار دهد.خصوصا اگر پرتال ما از بیرون(بر روی اینترنت) قابل دسترس باشد.
ده اشتباه امنیتی رایج در Sharepoint
نظرات مطالب
4# آموزش سیستم مدیریت کد Git : نصب و پیکر‌‏بندی

با سلام و عرض خسته نباشید به همه‌ی دوستان و همکاران

سوالی که بنده داشتم این بود که چرا و به چه علتی با وجود ابزاری مثل visual studio team foundation server 2010 , 2012  باید با ابزاری مثل git کار کرد و البته با توجه به اینکه دوستان این سایت یا وبلاگ عموما در حوضه دات نت هستند این سوال مهم‌تر هم میشه ، در مورد مطالب در خصوص git  باید بگم طرز کار کردن با این ابزار بسیار پیچیده‌تر و غیر اصولی‌تر از tfs هست ، مثلا اینکه خود فایل رو پس از تغییر نگهداری میکنه یک نقطه ضعفه ولی نویسنده مطلب از اون به عنوان نقطه قوت یاد کرده ، اگر فایل به صورت مجموعه تغییرات ذخیره بشه هم حجم اطلاعات ذخیره شده کاهش پیدا میکنه و هم منبع نگهداری سورس‌ها میتونه مثل ماشین زمان ما رو به جلو و عقب ببره و محدودیتی نخواهد داشت ، در هر حال با توجه به محصول مایکروسافت بودن tfs  و رایگان بودن git فکر کنم حتی مقایسه این دو حتی درست هم نباشه.

با تشکر از تمامی زحمات شما دوستان عزیز

نظرات مطالب
ساخت یک Form Generator ساده در MVC
با سلام و تشکر بابت مطلب مفیدتان
من برای ساخت پروژه فرم ساز به مسائلی برخورد کردم که به شرح زیر است:
1- دیتاهای وارد شده به چه صورت در دیتابیس ذخیره شوند؟من ابتدا در نظر داشتم به ازای هر فرمی که کاربر تعریف می‌کند یک جدول در دیتابیس ایجاد کنم  و برای هر کنترلی که در جدول گذاشته می‌شود یک فیلد به جدول فرم اضافه شود.اما با توجه به صحبت شما و روش XML که فرمودید در حال حاضر نمی‌توانم تصمیم گیری کنم که کدام روش بهتر است چون  طبق جستجویی که در نت کردم اگر نیاز به نوشتن کوئری‌های پیچیده بر روی داده‌های وارده شده باشد بهتر است جدول جداگانه ایجاد شود طبق این منبع:
http://stackoverflow.com/questions/14939973/storing-dynamic-form-and-data-entered-using-json
پروژه من هم نیاز به ساخت گزارش و داشبورد و BI از روی داده‌های وارد شده است.حال شما کدام انتخاب را انجام می‌دادید؟
2- نحوه ذخیره طراحی فرم چگونه است؟مثلا اگر در فرم لوگوی شرکت باید قرار گیرد چگونه باشد یا در فرم جدول 3 ستونی باشد که در هر سلول آن یک TextBox قرار می‌گیرد.اندازه هر کنترل  و مقدار پیش فرض   .....
آیا بهتر نیست اطلاعات کل فرم (شکل ظاهری فعلی فرم بدون داده) را به شکل JSON یا XML یا nvarchar(max)  ذخیره کرد؟
3- چطوری میتوان Enable  یا Visible بودن یک کنترل را وابسته کرد به مقدار کنترل دیگر در فرم مثلا اگر کمبو سال مالی برابر با 95 بود TextBox درصد سال 95 فعال در غیر اینصورت غیرفعال شود
ممنون میشم نظر خودتون را بفرمایید
نظرات مطالب
غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن
البته مشکل عدم رمزگشایی بعد از ریست شدن سرور مختص ویندوز نیست. در حالت پیش فرض محل ذخیره کلیدهای رمزنگاری تولید شده در حافظه است و همانطور که اشاره کردید باید با فراخوانی متد PersistKeysToFileSystem محلی را برای ذخیره سازی دائمی آنها تدارک دید. این محل میتواند پوشه ای در هاست شما باشد. (با توجه به عدم پشتیبانی از دات نت core توسط سرویس دهندگان در حال حاضر) و همچنین میتوان با پیاده‌سازی سفارشی از واسطهای IXmlDecryptor و IXmlEncryptor  و تزریق آنها به سیستم از یک Certificate غیرمعتبر استفاده کرد و نیازی به ثبت آن در Root store نیست. 
نظر شخصی بنده اینست که کلاسهای پیاده سازی شده برای رمزنگاری و رمزگشایی به شدت نگاه امنیتی بالایی را تدارک دیده است که در بیشتر سناریوها واقعا نیازی به اینهمه سطح از پیچیدگی وجود ندارد. در واقع میتوان با پیاده سازی واسط IDataProtectionProvider و تزریق آن به سیستم از روش رمزنگاری و رمزگشایی دلخواهی استفاده کرد.
نظرات مطالب
پیاده سازی Basic Authentication در ASP.NET MVC
برنامه‌هایی که عملیات بانکی را انجام میدهند از کدام روش بهره میبرند ؟

هر بانک  میتونه متفاوت باشه ولی استفاده از روش توکن‌ها میتواند جز بهترین‌ها باشد. همانند لینکی که خودتان دادید ، بانک ‌ها به جز اطلاعات امنیتی که به شما میدهند فقط و فقط به کاربرانی پاسخ میدهند که شماره تماس و کد IEMI آن‌ها در بانک اطلاعاتی به همراه اطلاعات و کدهایی که بانک به شما میدهد هش شده باشند. حتی برای ورود شما از شما رمز عبور میگیرند که آن را به صورت هش شده و آفلاین روی گوشی ذخیره میکنند تا ورود شما برای دفعات بعدی از آن طریق باشد تا اگر گوشی دست نااهلی افتاد (دزدیده یا گم شد) مجبور به ورود آن باشد.
مسائل مربوط به وب هم بیشتر بانکها از طریق دستگاه‌های رمز OTP شروع به ساخت کدهای زمان دار میکنند.
- آیا این روش JWT هم با برنامه‌های موبایل قابل انجام هست ؟

بله، مهم این است که توکن را داشته باشید و به جای استفاده از Basic از Bearer استفاده کنید. نمونه ای از پیاده سازی آن در جاوا و اندروید

- اگر از https  استفاده شود امنیت روش Basic Authentication قابل قبول هست ؟

بله با استفاده از این روش میتوان این قسمت را از دید مخفی کرد ، مگر اینکه شخصی در شبکه با اختلال در سمت کلاینت همانند حملات HITM یا دیگر حملات مشابه دخالت کند. این روش بیشتر برای برنامه‌های موبایل مناسب‌تر است که هر درخواست توسط کدهای ما ایجاد و ارسال میشود. در غیر اینصورت در باقی موارد چندان امنیتی ندارد. به عنوان مثال احتمال کش شدن این نوع درخواست از طریق مرورگر بسیار بالاست که ممکن است به حملات CSRF دامن بزند. در حالت امنیتی بیشتر میتوان به Http Digest هم اشاره کرد که در این جا سادگی Basic را ندارد ولی تبادل کلید و هش کردن مقادیر از طریق آن ممکن است.
مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 8 - فعال سازی ASP.NET MVC
پیشنیازهای بحث (از قسمت 8 به بعد این سری)
اگر پیشتر سابقه‌ی کار کردن با ASP.NET MVC را ندارید، نیاز است «15 مورد» ابتدایی مطالب ASP.NET MVC سایت را پیش از ادامه‌ی این سری مطالعه کنید؛ از این جهت که این سری از مطالب «ارتقاء» نام دارند و نه «بازنویسی مجدد». دراینجا بیشتر تفاوت‌ها و روش‌های تبدیل کدهای قدیمی، به جدید را بررسی خواهیم کرد؛ تا اینکه بخواهیم تمام مطالبی را که وجود دارند از صفر بازنویسی کنیم.


فعال سازی ASP.NET MVC

تا اینجا خروجی برنامه را صرفا توسط میان افزار app.Run نمایش دادیم. اما در نهایت می‌خواهیم یک برنامه‌ی ASP.NET MVC را برفراز ASP.NET Core 1.0 اجرا کنیم و این قابلیت نیز به صورت پیش فرض غیرفعال است. برای فعال سازی آن نیاز است ابتدا بسته‌ی نیوگت آن‌را نصب کرد. سپس سرویس‌های مرتبط با آن‌را ثبت و معرفی نمود و در آخر میان افزار خاص آن‌را فعال کرد.


نصب وابستگی‌های ASP.NET MVC

برای این منظور بر روی گره references کلیک راست کرده و گزینه‌ی manage nuget packages را انتخاب کنید. سپس در برگه‌ی browse آن Microsoft.AspNetCore.Mvc را جستجو کرده و نصب نمائید:


انجام این مراحل معادل هستند با افزودن یک سطر ذیل به فایل project.json برنامه:
 {
    "dependencies": {
      //same as before  
      "Microsoft.AspNetCore.Mvc": "1.0.0"
 },


تنظیم سرویس‌ها و میان افزارهای ASP.NET MVC

پس از نصب بسته‌ی نیوگت ASP.NET MVC، دو تنظیم ذیل در فایل آغازین برنامه، برای شروع به کار با ASP.NET MVC کفایت می‌کنند:
الف) ثبت یکجای سرویس‌های ASP.NET MVC
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

ب) معرفی میان افزار ASP.NET MVC
public void Configure(IApplicationBuilder app)
{
   app.UseFileServer();
   app.UseMvcWithDefaultRoute();
در مورد متد UseFileServer در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 4 - فعال سازی پردازش فایل‌های استاتیک» بیشتر بحث شد.
در اینجا دو متد UseMvc و UseMvcWithDefaultRoute را داریم. اولی، امکان تعریف مسیریابی‌های سفارشی را میسر می‌کند و دومی به همراه یک مسیریابی پیش فرض است.


افزودن اولین کنترلر برنامه و معرفی POCO Controllers


در ویژوال استودیو بر روی نام پروژه کلیک راست کرده و پوشه‌ی جدیدی را به نام کنترلر اضافه کنید (تصویر فوق). سپس به این پوشه کلاس جدید HomeController را با این محتوا اضافه کنید:
namespace Core1RtmEmptyTest.Controllers
{
    public class HomeController
    {
        public string Index()
        {
            return "Running a POCO controller!";
        }
    }
}
در ادامه برای اینکه فایل index.html موجود در پوشه‌ی wwwroot بجای محتوای اکشن متد Index ما نمایش داده نشود (با توجه به تقدم و تاخر میان افزارهای ثبت شده‌ی در کلاس آغازین برنامه)، این فایل را حذف کره و یا تغییر نام دهید.
سپس برنامه را اجرا کنید. این خروجی باید قابل مشاهده باشد:


اگر با نگارش‌های قبلی ASP.NET MVC کار کرده باشید، تفاوت این کنترلر با آن‌ها، در عدم ارث بری آن از کلاس پایه‌ی Controller است. به همین جهت به آن POCO Controller نیز می‌گویند (plain old C#/CLR object).
در ASP.NET Core، همینقدر که یک کلاس public غیر abstract را که نامش به Controller ختم شود، داشته باشید و این کلاس در اسمبلی باشد که ارجاعی را به وابستگی‌های ASP.NET MVC داشته باشد، به عنوان یک کنترلر معتبر شناخته شده و مورد استفاده قرار خواهد گرفت. در نگارش‌های قبلی، شرط ارث بری از کلاس پایه Controller نیز الزامی بود؛ اما در اینجا خیر. هدف از آن نیز کاهش سربارهای وهله سازی یک کنترلر است. اگر صرفا می‌خواهید یک شیء را به صورت JSON بازگشت دهید، شاید وهله سازی یک کلاس ساده، بسیار بسیار سریعتر از نمونه سازی یک کلاس مشتق شده‌ی از Controller، به همراه تمام وابستگی‌های آن باشد.

 البته هنوز هم مانند قبل، کنترلرهای مشتق شده‌ی از کلاس پایه‌ی Controller قابل تعریف هستند:
using Microsoft.AspNetCore.Mvc;
 
namespace Core1RtmEmptyTest.Controllers
{
    public class AboutController : Controller
    {
        public IActionResult Index()
        {
            return Content("Hello from DNT!");
        }
    }
}
با این خروجی:


تفاوت دیگری را که ملاحظه می‌کنید، خروجی IActionResult بجای ActionResult نگارش‌های قبلی است. در اینجا هنوز هم ActionResult را می‌توان بکار برد و اینبار ActionResult، پیاده سازی پیش فرض اینترفیس IActionResult است.
و اگر بخواهیم در POCO Controllers شبیه به return Content فوق را پیاده سازی کنیم، نیاز است تا تمام جزئیات را از ابتدا پیاده سازی کنیم (چون کلاس پایه و ساده ساز Controller در اختیار ما نیست):
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
 
namespace Core1RtmEmptyTest.Controllers
{
    public class HomeController
    {
        [ActionContext]
        public ActionContext ActionContext { get; set; }
 
        public HttpContext HttpContext => ActionContext.HttpContext;
 
        public string Index()
        {
            return "Running a POCO controller!";
        }
 
        public IActionResult About()
        {
            return new ContentResult
            {
                Content = "Hello from DNT!",
                ContentType = "text/plain; charset=utf-8"
            };
        }
    }
}
همانطور که ملاحظه می‌کنید اینبار بجای return Content ساده، باید وهله سازی شیء ContentResult از ابتدا صورت گیرد؛ به همراه تمام جزئیات آن.
به علاوه در اینجا نحوه‌ی دسترسی به HttpContext را هم مشاهده می‌کنید. ویژگی ActionContext سبب تزریق اطلاعات آن به کنترلر جاری شده و سپس از طریق آن می‌توان به HttpContext و تمام قابلیت‌های آن دسترسی یافت.
اینجا است که می‌توان میزان سبکی و سریعتر بودن POCO Controllers را احساس کرد. شاید در کنترلری نیاز به این وابستگی‌ها نداشته باشید. اما زمانیکه کنترلری از کلاس پایه‌ی Controller مشتق می‌شود، تمام این وابستگی‌ها را به صورت پیش فرض و حتی در صورت عدم استفاده، در اختیار خواهد داشت و این در اختیار داشتن یعنی وهله سازی شدن تمام وابستگی‌های مرتبط با شیء پایه‌ی Controller. به همین جهت است که POCO Controllers بسیار سبک‌تر و سریع‌تر از کنترلرهای متداول مشتق شده‌ی از کلاس پایه‌ی Controller عمل می‌کنند.