using System.Linq;
namespace SecurityModule
{
public static class SafePassword
{
public static ISet<string> BadPasswords = new HashSet<string>
{
"password",
"password1",
"123456",
"12345678",
"1234",
"qwerty",
"12345",
"dragon",
"******",
"baseball",
"football",
"letmein",
"monkey",
"696969",
"abc123",
"mustang",
"michael",
"shadow",
"master",
"jennifer",
"111111",
"2000",
"jordan",
"superman",
"harley",
"1234567",
"iloveyou",
"trustno1",
"sunshine",
"123123",
"welcome"
};
public static bool IsSafePasword(this string data)
{
if (string.IsNullOrWhiteSpace(data)) return false;
if (data.Length < 5) return false;
if (BadPasswords.Contains(data.ToLowerInvariant())) return false;
if (data.AreAllCharsEuqal()) return false;
return true;
}
public static bool AreAllCharsEuqal(this string data)
{
if (string.IsNullOrWhiteSpace(data)) return false;
data = data.ToLowerInvariant();
var firstElement = data.ElementAt(0);
var euqalCharsLen = data.ToCharArray().Count(x => x == firstElement);
if (euqalCharsLen == data.Length) return true;
return false;
}
}
}
public partial class RegisterController : Controller
{
//...
[HttpPost]
[OutputCache(Location = OutputCacheLocation.None, NoStore = true)]
public virtual ActionResult CheckPassword(string password1)
{
return Json(password1.IsSafePasword());
}
}
using System.ComponentModel.DataAnnotations;
using System.Web.Mvc;
namespace MyBlog.Models
{
public class RegisterViewModel
{
//...
[Display(Name = "کلمه عبور")]
[Required(ErrorMessage = "لطفا کلمه عبور خود را وارد نمائید")]
[DataType(DataType.Password)]
[StringLength(50, MinimumLength = 5, ErrorMessage = "حداقل طول کلمه عبور 5 حرف است")]
[Remote(action: "CheckPassword", controller: "Register", HttpMethod = "POST",
ErrorMessage = "کلمه عبور وارد شده را راحت می‌توان حدس زد!")]
public string Password1 { get; set; }
}
}
private string name = string.Empty;
public string Name
{
get { return this.name; }
set
{
if (value == null)
{
this.name = "";
return;
}
this.name = value;
}
}
public IList<string> GetCultures()
{
//...
}
public static class LanguageExtender
{
public static string GetSafeStringValue(this XElement input)
{
return (input == null) ? string.Empty : input.Value;
}
public static DateTime GetSafeDateValue(this XElement input)
{
return (input == null) ? DateTime.MinValue : DateTime.Parse(input.Value);
}
}
پروسه Full Load شامل مراحل زیر بود:
روی هم رفته Full Load مسئله ای مشکل ساز بود، زیرا نیاز به زمانی برای بارگذاری مجدد داده‌ها داشت و مسئله‌ی مهم‌تر نداشتن امکان دستیابی به گزارشاتی تاریخچه ای با ماهیت زمان برای مشتریان کسب وکار بود. به این دلیل که همواره یک کپی از آخرین داده‌های موجود در سیستم عملیاتی درون DW قرار می‌گرفت؛ که با بکارگیری Full Load اغلب قادر به ارائه‌ی این نوع از گزارشات نبودیم، بدین ترتیب سازمان‌ها به نسل دوم روی آورند که در این دیدگاه از مفهوم Incremental Load استفاده می‌شود. اشکال زیر مراحلی که در این روش انجام می‌شود را نمایان می‌سازد:
Incremental Load with an Extract In area
Incremental Load without an Extract In area
مراحل Incremental Load شامل:
تفاوت‌های اصلی میان Full Load و Incremental Load در این است که در Incremental Load:
ترکیب این عوامل برای ساخت Incremental Load کارآمد تر، منجر به پیچیده‌تر شدن پیاده سازی و نگهداری آن نیز می‌شود.
فرآیند لود افزایشی ETL، بایست قادر به شناسائی رکوردهای تغییریافته در مبداء باشد، که این عمل با استفاده از هر یک از تکنیک‌های Push یا Pull انجام می‌شود.
- ایده‌آل وجود داشتن یک ستون Last Changed در سیستم مبداء است؛ که از آن می‌توان جهت انتخاب رکوردهای تغییر یافته استفاده نمود.
- چنانچه ستون Last Changed وجود نداشته باشد، تمامی رکوردهای مبداء باید با رکوردهای مقصد مقایسه شود.
تفاوت این دو روش به شرح زیر است:
مسئله ای که در هر دو مورد وجود دارد Load اضافه ای است؛ که روی سیستم مبداء وجود دارد و می‌تواند Performance سیستم‌های OLTP را تحت تاثیر قرار دهد. به هر روی سناریو نخست معمولاً کاراتر از سناریویی است که از Trigger استفاده می‌کند.
پس از شناسائی رکوردهایی که در مبداء تغییر یافته اند، نیاز داریم تا این تغییرات در مقصد اعمال شود. در این قسمت به معرفی الگوهایی که برای اعمال این تغییرات وجود دارد می‌پردازیم.
تشخیص چگونگی اضافه نمودن تغییرات در مقصد تابع دو عامل زیر است:
فلوچارت زیر نشان می‌دهد، به چه شکل جداول مقصد متاثر از چگونگی پردازش رکوردهای مبداء قرار دارند. توجه داشته باشید که عمل بررسی بطور جداگانه و در یک لحظه صورت می‌گیرد.
Kimball Type II Slowly Changing Dimension نمونه ای از الگوی Versioned Insert است؛ که در آن نمونه ای از یک موجودیت دارای ورژن‌های متعددی است. مطابق تصویر زیر؛ این الگو به ستون‌های اضافه ای نیاز دارند که وضعیت نمونه ای از یک رکورد را نمایش دهد.
این ستون‌ها به شرح زیر هستند:
برای مثال شکل زیر؛ بیانگر وضعیت اولیه رکوردی در این الگو است:
فرض کنید که این رکورد در تاریخ March 2 , 2010 در سیستم مبداء تغییر می‌کند. فرآیند ETL این تغییر را شناسائی می‌کند و همانند تصویر زیر؛ به شکل نمونه ای ثانویه از این رکورد، اقدام به درج آن می‌کند.
توجه داشته باشید زمانی که رکورد دوم در جدول درج می‌شود، به منظور بازتاب این تغییر؛ رکورد اول به شکل زیر بروزرسانی می‌گردد:
در برخی از پیاده سازی‌های DW عمدتاً از الگوی Versioned Insert استفاده می‌شود و هرگز از الگوی Update استفاده نمی‌شود. مزیت این استراتژی در این است که تمامی تاریخچه تغییرات ردیابی و ثبت می‌شود. به هر روی غالباً هزینه ثبت کردن این تغییرات منجر به ایجاد نسخه‌های زیادی از تغییرات می‌شود. تیم DW برای مواردی که تغییرات متاثر از گزارشات تاریخچه ای نیستند، می‌توانند الگوی Update را در نظر گیرند.
الگوی Update روی رکورد موجود، تغییرات سیستم مبداء را بروزرسانی می‌کند. مزیت این روش در این است که همواره یک رکورد وجود دارد و در نتیجه باعث ایجاد Queryهای کارآمدتر می‌شود. تصویر زیر بیانگر ستون هایی است که برای پشتیبانی از الگوی Update بایست ایجاد کرد.
این ستون‌ها به شرح زیر هستند:
موارد اصلی الگوی Update عبارتند از:
یک روش دیگر برای در نظر گرفتن موارد فوق؛ اضافه کردن یک جدول برای درج ورژن‌ها به الگوی Update است که در شکل زیر نشان داده شده است.
اضافه نمودن یک جدول تاریخچه، که تمامی تغییرات سیستم مبداء را ثبت می‌کند؛ نظارت و ممیزی داده‌ها را نیز فراهم می‌کند و همچنین بروزرسانی‌های کارآمد مبتنی بر مجموعه را برای جداول DW به ارمغان می‌آورد.
این الگو غالباً در جداول حجیم Fact که بروزرسانی آنها پر هزینه است استفاده می‌شود. شکل زیر منطق استفاده شده در این الگو را نشان می‌دهد.
هم اکنون پس از آشنایی با مفاهیم و الگوهای توزیع داده‌ها به ارائه تعدادی نمونه می‌پردازیم؛ که بتوان این ایده‌ها و الگوها را در عمل پوشش داد.
هر یک از الگوهای Update Pattern و Versioned Insert Pattern می‌توانند برای انواعی از جداول بکار روند که معروفترین آنها توسط Kimball ساخته شده اند.
مطابق تصویر زیر جدولی که تنها حاوی ورژن فعلی رکورد هاست؛ از Update Dataflow Pattern استفاده می‌کند.
مواردی که در مورد این گردش کاری باید در نظر داشت به شرح زیر است:
- راه دیگر فرستادن تغییرات رکوردها به یک جدول کاری است که پس از پایان یافتن فرآیند Update ، خالی (Truncate) می‌شود.
- مزیت نگهداری تمامی رکوردها در یک جدول تاریخچه؛ ایجاد یک دنباله ممیزی است که می‌تواند برای نظارت بر داده‌ها به منظور نمایان ساختن موارد مطرح شده توسط مصرف کننده‌های کسب و کار استفاده شود.
شکل زیر نمایش دهنده چگونگی پیاده سازی Update Dataflow Pattern در یک SSIS می‌باشد:
این SSIS شامل عناصر زیر است:
به منظور تشخیص اینکه رکورد در جدول مقصد وجود دارد از “lkpPersonContact” استفاده می‌کنیم.
با استفاده از “DidRecordChange” مبداء و مقصد مقایسه می‌شوند. اگر تفاوتی بین مبداء و مقصد وجود نداشت؛ رکورد نادیده گرفته می‌شود. چنانچه بین مبداء و مقصد تفاوت وجود داشت؛ رکورد در جدول تاریخچه درج خواهد شد.
رکوردها در جدول مقصد درج خواهند شد در صورتیکه در آن وجود نداشته باشند.
رکوردها در جدول تاریخچه مقصد درج خواهند شد، در صورتیکه (در مقصد) وجود داشته باشند.
پس از اتمام Data Flow یک روال Post-processing مسئولیت بروزرسانی رکوردهای جدول اصلی و رکوردهای ذخیره شده در جدول تاریخچه را بر عهده دارد که می‌تواند مطابق تصویر زیر با استفاده از یک Execute Process Task پیاده سازی شود.
PostProcess مسئولیت اجرای تمامی فعالیت‌های زیر را در این الگو برعهده دارد که شامل:
تصویر زیر بیانگر انجام این عملیات با استفاده از ابزارهای ETL است.
در نگاه نخستین ممکن است Data Flow از نوع اصلی خود پیچیده‌تر به نظر آید؛ که در واقع این گونه نیز هست، زیرا در فاز توسعه بیشتر Frameworkها جهت پیاده سازی به یک زمان اضافه‌تری نیاز دارند. به هر روی این زمان جهت اجتناب از هزینه روزانه تطبیق داده‌ها گرفته خواهد شد.
مزایای حاصل شده از افزودن این منطق اضافی عبارت است از:
بهره برداران ETL و ناظران اطلاعات می‌توانند با استفاده از خلاصه تعداد رکوردها درک بیشتری درباره فعالیت‌های آن کسب کنند. پس از آنکه تعداد رکوردها، مشکوک به نظر آمد؛ تحقیقات بیشتری می‌تواند اتفاق افتد. (با عمیق‌تر شدن در جزئیات گزارشات)
جدولی که به صورت Versioned Insert پر شده است می‌تواند از Versioned Insert Dataflow Pattern استفاده کند. همانند شکل زیر که گردش کار در آن برای کارآئی بیشتر بازنگری شده است.
توجه داشته باشید Data Flow در این روش شامل:
شکل زیر SSIS versioned insert data flow pattern را نشان می‌دهد:
تعدادی نکته در Data Flow فوق وجود دارد که عبارتند از:
الگوی Versioned Insert نسبت الگوی Update دارای پیاده سازی ساده‌تر و فعالیت‌های I/O کمتری است. از منظر دیگر، جدولی که از الگوی Update استفاده می‌کند، دارای تعداد رکوردهای کمتری است که می‌تواند به معنای Performance بهتر نیز تعبیر شود. ممکن است سوالی مطرح شود، اینکه چرا برای انجام کار به جدول تاریخچه نیاز است؛ این جدول را که نمی‌توان Truncate نمود، پس چرا به منظور بروزرسانی از جدول اصلی استفاده می‌شود؟ پاسخ این پرسش در این است که جدول تاریخچه، ناظر اطلاعات و ممیزین داده را قادر می‌سازد، تغییرات در طول زمان را پیگیری نمایند.
بروزرسانی Dimension موارد زیر را شامل می‌شود:
چنانچه با یک Dimension کوچک مواجه هستید (با مقدار هزاران رکورد یا کمتر، که با صدها هزار رکورد یا بیشتر ضدیت دارد)، می‌توانید از تبدیل “Slowly Changing Dimension” که بصورت Built-in در SSIS موجود است، استفاده نمائید. به هر روی با آنکه این تبدیل چندین ویژگی محدودکننده Performance دارد، اغلب کارآمدتر از پروسسه هایی که توسط خودتان ایجاد می‌شود. در واقع فرآیند بارگذاری در جداول Dimension با مقایسه داده‌ها بین مبداء و مقصد انجام می‌شود. به طور معمول مقایسه روی یک ورژن جدید و یا مجموعه ای از سطرهای جدید یک جدول با مجموعه داده‌های موجود در جدول متناظرش صورت می‌گیرد. پس از تشخیص چگونگی تغییر در داده ها، یک سری عملیات درج و بروزرسانی انجام می‌شود. شکل زیر نمونه ای از پردازش سریع در Dimension را نمایش می‌دهد؛ که شامل مراحل اساسی زیر است:
با Merge Join ارتباطی بین رکوردهای مبداء و رکوردهای مقصد برقرار می‌شود. (در این مثال “CustomerAlternateKey”). هنگامی که از این دیدگاه استفاده می‌کنید، خاطر جمع شوید که نوع Join با مقدار “Left outer join” تنظیم شده است؛ بدین ترتیب قادر هستید تا رکوردهای جدید را از مبداء تشخیص دهید؛ از آنجا که هنوز در جدول Dimension قرار نگرفته اند.
گام پایانی به منظور تشخیص اینکه آیا رکورد، جدید یا تغییر یافته است (یا بلاتکلیف است)، مقایسه داده هاست. شکل زیر نمایش می‌دهد چگونه این ارزیابی با استفاده از تبدیل “Conditional Spilt” صورت می‌گیرد.
Conditional Spilt مستقیماً با استفاده از یک Adapter تعریف شده روی مقصد یا یک جدول کاری بروزرسانی که از یک Adapter تعریف شده روی مقصد استفاده می‌کند؛ توسط مجموعه دستور Update زیر، رکوردها را در جدول Dimension قرار می‌دهد. دستور Update زیر مستقیماً با استفاده از روش Join روی جدول Dimension و جدول کاری، مجموعه ای را بصورت انبوه بروزرسانی می‌کند.
UPDATE AdventureWorksDW2008R2.dbo.DimCustomer
SET AddressLine1 = stgDimCustomerUpdates.AddressLine1
, AddressLine2 = stgDimCustomerUpdates.AddressLine2
, BirthDate = stgDimCustomerUpdates.BirthDate
, CommuteDistance = stgDimCustomerUpdates.CommuteDistance
, DateFirstPurchase = stgDimCustomerUpdates.DateFirstPurchase
, EmailAddress = stgDimCustomerUpdates.EmailAddress
, EnglishEducation = stgDimCustomerUpdates.EnglishEducation
, EnglishOccupation = stgDimCustomerUpdates.EnglishOccupation
, FirstName = stgDimCustomerUpdates.FirstName
, Gender = stgDimCustomerUpdates.Gender
, GeographyKey = stgDimCustomerUpdates.GeographyKey
, HouseOwnerFlag = stgDimCustomerUpdates.HouseOwnerFlag
, LastName = stgDimCustomerUpdates.LastName
, MaritalStatus = stgDimCustomerUpdates.MaritalStatus
, MiddleName = stgDimCustomerUpdates.MiddleName
, NumberCarsOwned = stgDimCustomerUpdates.NumberCarsOwned
, NumberChildrenAtHome = stgDimCustomerUpdates.NumberChildrenAtHome
, Phone = stgDimCustomerUpdates.Phone
, Suffix = stgDimCustomerUpdates.Suffix
, Title = stgDimCustomerUpdates.Title
, TotalChildren = stgDimCustomerUpdates.TotalChildren
FROM AdventureWorksDW2008.dbo.DimCustomer DimCustomer
INNER JOIN dbo.stgDimCustomerUpdates ON
DimCustomer.CustomerAlternateKey = stgDimCustomerUpdates.CustomerAlternateKey جداول Fact به پردازش‌های منحصر به فردی نیازمند هستند، نخست به کلیدهای Surrogate جدول Dimension نیاز دارند تا Measureهای محاسبه شدنی را بدست آورند. این اعمال از طریق تبدیلات Lookup، Merge Join و Derived Column صورت می‌گیرد. با بروزرسانی ها، تفاضل رکوردها و یا Snapshot بیشتر این فرآیندهای دشوار انجام می‌شوند.
روی اغلب جداول Fact عمل درج صورت می‌گیرد؛ که کار متداولی در جدول Fact می‌باشد. شاید ساده‌ترین کار که در فرآیند ساخت ETL صورت می‌گیرد، عملیات درج روی تنها تعدادی از جدول Fact می‌باشد. درج کردن در صورت لزوم بارگذاری انبوه داده ها، مدیریت شاخص‌ها و مدیریت پارتیشن‌ها را شامل می‌شود.
بروزرسانی روی جداول Fact معمولاً به یکی از سه طریق زیر انجام می‌گیرد:
در موردی که تغییرات با فرکانس کمی روی جدول Fact صورت می‌گیرد و یا فرآیند بروزرسانی قابل مدیریت است؛ ساده‌ترین روش انجام یک دستور Update روی جدول Fact می‌باشد. نکته مهمی که هنگام انجام بروزرسانی باید به خاطر داشته باشید، استفاده از روش بروزرسانی مبتنی بر مجموعه است؛ به همان طریق که در قسمت الگوهای Dimension ذکر آن رفت.
در طریقی دیگر (درج compensating) می‌توان اقدام به درج رکورد تغییر یافته نمود، تا ترجیحاً بروزرسانی روی آن صورت گیرد. این استراتژی به سادگی داده‌های جدول Fact میان سیستم مبداء و مقصد را که تغییر یافته اند، به صورت یک رکورد جدید درج خواهد کرد. تصویر زیر مثالی از اجرای موارد فوق را نمایش می‌دهد.
در آخرین روش از یک دستور SQL MERGE استفاده می‌شود که در آن با استفاده از ادغام و مقایسه، تمامی داده‌های جدید و تغییر یافته جدول Fact، درج و یا بروزرسانی می‌شوند. نمونه ای از استفاده دستور Merge به شرح زیر است:
MERGE dbo.FactSalesQuota AS T USING SSIS_PDS.dbo.stgFactSalesQuota AS S ON T.EmployeeKey = S.EmployeeKey AND T.DateKey = S.DateKey WHEN MATCHED AND BY target THEN INSERT(EmployeeKey, DateKey, CalendarYear, CalendarQuarter, SalesAmountQuota) VALUES(S.EmployeeKey, S.DateKey, S.CalendarYear, S.CalendarQuarter, S.SalesAmountQuota) WHEN MATCHED AND T.SalesAmountQuota != S.SalesAmountQuota THEN UPDATE SET T.SalesAmountQuota = S.SalesAmountQuota ;
زمانیکه یک ارجاع در جدول Fact به یک عضو Dimension که هنوز بارگذاری نشده‌است بوجود آید؛ یک Inferred Member تعبیر می‌شود. به سه طریق می‌توان این Inferred Memberها را مدیریت نمود:
شکل زیر این موارد را نمایش می‌دهد:
fetchProducts(categoryId?: number) {
console.log(categoryId);
this.products = [];
if (categoryId === undefined || categoryId.toString() === "undefined") {
return;
} 
> npm install ng2-toasty --save
npm ERR! Error: EPERM: operation not permitted, rename
"styles": [
"../node_modules/bootstrap/dist/css/bootstrap.min.css",
"../node_modules/ng2-toasty/bundles/style-bootstrap.css",
"styles.css"
], import { ToastyModule } from "ng2-toasty";
@NgModule({
imports: [
BrowserModule,
ToastyModule.forRoot(), <ng2-toasty [position]="'top-right'"></ng2-toasty>
import { ToastyService, ToastOptions } from "ng2-toasty";
export class ProductGroupComponent implements OnInit {
constructor(
private productItemsService: ProductItemsService,
private toastyService: ToastyService) { }
fetchProducts(categoryId?: number) {
console.log(categoryId);
this.products = [];
if (categoryId === undefined || categoryId.toString() === "undefined") {
this.toastyService.error(<ToastOptions>{
title: "Error!",
msg: "Please select a category.",
theme: "bootstrap",
showClose: true,
timeout: 5000
});
return;
} 
this.productItemsService.getCategories().subscribe(
data => {
this.categories = data;
},
err => console.log("get error: ", err)
); > ng g cl app.error-handler
installing class create src\app\app.error-handler.ts
import { ErrorHandler } from "@angular/core";
export class AppErrorHandler implements ErrorHandler {
handleError(error: any): void {
console.log("Error:", error);
}
} import { NgModule, ErrorHandler } from "@angular/core";
import { AppErrorHandler } from "./app.error-handler";
@NgModule({
providers: [
{ provide: ErrorHandler, useClass: AppErrorHandler }
] [HttpGet("[action]/{categoryId:int}")]
public async Task<IActionResult> GetProducts(int categoryId)
{
throw new Exception(); this.productItemsService.getProducts(categoryId).subscribe(
data => {
this.products = data;
this.isLoadingProducts = false;
}// ,
// err => {
// console.log("get error: ", err);
// this.isLoadingProducts = false;
// }
); 
import { ToastyService, ToastOptions } from "ng2-toasty";
import { ErrorHandler } from "@angular/core";
export class AppErrorHandler implements ErrorHandler {
constructor(private toastyService: ToastyService) {
}
handleError(error: any): void {
// console.log("Error:", error);
this.toastyService.error(<ToastOptions>{
title: "Error!",
msg: "Fatal error!",
theme: "bootstrap",
showClose: true,
timeout: 5000
});
}
} Uncaught Error: Can't resolve all parameters for AppErrorHandler: (?).
import { ErrorHandler, Inject } from "@angular/core";
export class AppErrorHandler implements ErrorHandler {
constructor(
@Inject(ToastyService) private toastyService: ToastyService
) {
} import { ToastyService, ToastOptions } from "ng2-toasty";
import { ErrorHandler, Inject, NgZone } from "@angular/core";
import { LocationStrategy, PathLocationStrategy } from "@angular/common";
export class AppErrorHandler implements ErrorHandler {
constructor(
@Inject(NgZone) private ngZone: NgZone,
@Inject(ToastyService) private toastyService: ToastyService,
@Inject(LocationStrategy) private locationProvider: LocationStrategy
) {
}
handleError(error: any): void {
// console.log("Error:", error);
const url = this.locationProvider instanceof PathLocationStrategy ? this.locationProvider.path() : "";
const message = error.message ? error.message : error.toString();
this.ngZone.run(() => {
this.toastyService.error(<ToastOptions>{
title: "Error!",
msg: `URL:${url} \n ERROR:${message}`,
theme: "bootstrap",
showClose: true,
timeout: 5000
});
});
// IMPORTANT: Rethrow the error otherwise it gets swallowed
// throw error;
}
} 
>npm install >ng build --watch
>dotnet restore >dotnet watch run
<li>Item 1</li> <li>Item 2</li>
<li>Item 1</li> <li>Item 2</li> <li>Item 3</li>
<li>Item 0</li> // <= New item <li>Item 1</li> <li>Item 2</li> <li>Item 3</li>
<li key={0}>Item 0</li> // <= New item
<li key={1}>Item 1</li>
<li key={2}>Item 2</li>
<li key={3}>Item 3</li> @page "/"
<button class="btn btn-primary" @onclick="addPerson">Add Person</button>
<ul class="mt-5">
@foreach (var person in People)
{
<li>@person.Id, @person.Name</li>
}
</ul>
@code{
List<Person> People = new()
{
new() { Id = 1, Name = "User 1" },
new() { Id = 2, Name = "User 2" },
};
int LastId = 2;
void addPerson()
{
People.Insert(0, new() { Id = ++LastId, Name = $"User {LastId}" });
}
class Person
{
public int Id { set; get; }
public string Name { set; get; }
}
} 
<ul class="mt-5">
@foreach (var person in People)
{
<li @key="person.Id">@person.Id, @person.Name</li>
}
</ul> 
//dynamic reflection
PropertyInfo property = typeof (MyClass).GetProperty("Name");
MethodInfo method = typeof (MyClass).GetMethod("SomeMethod");
public string TextBoxFor<T>(Expression<Func<T,object>> expression);
<%= this.TextBoxFor(model => model.FirstName); %>
public PropertyInfo GetProperty<T>(Expression<Func<T, object>> expression)
{
var memberExpression = expression.Body as MemberExpression;
if (memberExpression == null)
throw new InvalidOperationException("Not a member access.");
return memberExpression.Member as PropertyInfo;
}
public class AddressMap : DomainMap<Address>
{
public AddressMap()
{
Map(a => a.Address1);
}
}
A simple yet organized project template for building ASP.NET Core APIs in .NET Core 3.1
Tools and Frameworks Used
