הדרך הרשמית לבצע זאת בEntity Framework Core היא שימוש בפקודה dotnet ef dbcontext scaffold, אשר תיצור את הDbContext ואת הEntities בצורה אוטומטית, אחת מהמעלות הבולטות של השימוש בפקודה היא השינוי של שמות המחלקות והProperties כך שיתאימו למוסכמות של C# (ניתן לבטל את הפיצר באמצעות הפרמטר use-database-names--) כמו כן באמצעות הכלי ניתן להגדיר דברים רבים נוספים הקשורים ליצירה של המחלקות.

דוגמא בסיסית (שימוש בlocaldb):

dotnet ef dbcontext scaffold "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=DatabaseName" Microsoft.EntityFrameworkCore.SqlServer

דוגמא נרחבת:

dotnet ef dbcontext scaffold "Server=ServerName; Database=DatabaseName; User Id=UserId; Password=Password" Microsoft.EntityFrameworkCore.SqlServer   --context=DbContext --context-dir  DbDir --data-annotations --output-dir DbDir/Entities

לשימוש בכלי מומלץ להתקינו גלובלית:

dotnet tool install --global dotnet-ef

להוסיף על דבריו הנכונים של @yossiz:

נתונים שתי חתימות:

perform(instruction: Instruction<UnaryOperands>): void;
perform(instruction: Instruction<BinaryOperands>): void;

החתימה הנכונה תיקבע לפי זהות הפרמטר הניתן לInstruction (הסוג של T), כיוון שהסוג שמועבר בדוגמה לInstruction הוא מסוג Union פתוח של שני הסוגים (UnaryOperands | BinaryOperands) המהדר אינו יכול לקבוע את זהות החתימה הנכונה משום שבזמן הכתיבה לא ניתן לדעת את הנתון הזה (זהות הסוג הספיציפי בתוך הUnion).

די ברור מדוע הקוד דלהלן אינו תקין:

interface A { field1: number; }
interface B { field2: number; }

function perform(param: A): void;
function perform(param: B): void;
function perform(param: A | B): void { }

let param: A | B;

perform(param);

המהדר יעבור חתימה אחר חתימה בנסיון למצוא את החתימה המתאימה, בסיום אם נכשל יספק אינדיקציה עבור כל חתימה מדוע אינה מתאימה:

No overload matches this call.

Overload 1 of 2, '(param: A): void', gave the following error.
  Argument of type 'A | B' is not assignable to parameter of type 'A'.
    Property 'field1' is missing in type 'B' but required in type 'A'.

Overload 2 of 2, '(param: B): void', gave the following error.
  Argument of type 'A | B' is not assignable to parameter of type 'B'.
    Property 'field2' is missing in type 'A' but required in type 'B'.ts(2769)

לסיכום
הפיצרים Overloading וUnion types קצת בעייתיים לשימוש בו זמני, משום שעבור השימוש בOverloading דרוש סוג קונקרטי (אלא אם כן החתימה בעצמה מצהירה על Union).

@מוטי-אורן אתה יכול להשתמש בUtility Type דלהלן כדי להפוך את כל השדות החסרים בBase לOptional:

/**
 *  Construct a type with the properties of TOptional in which all keys not included in TRequired are marked as optional
 */
type MarkBaseMissingPropertiesAsOptional<TRequired, TOptional extends TRequired> = Partial<Exclude<TOptional, keyof TRequired>> & Pick<TOptional, keyof TRequired>;

שימוש

MarkBaseMissingPropertiesAsOptional<UnaryOperands, BinaryOperands>

תוצאה

{
    dst: string;
    src?: string;
}

נאלצתי לנחש חלק מהקוד. השורות דלהלן מתקמפלות כראוי.

type OptionalExceptFor<T, TRequired extends keyof T> = Partial<T> & Pick<T, TRequired>

interface UnaryOperands { dst: number; }
interface BinaryOperands extends UnaryOperands { src: number; }
interface Instruction<T extends UnaryOperands> { operands: T; }

function perform(instruction: Instruction<UnaryOperands>): void
function perform(instruction: Instruction<BinaryOperands>): void
function perform(instruction: Instruction<OptionalExceptFor<BinaryOperands, 'dst'>>): void { }

perform({ operands: { dst: 45 } });

המתודה Operate איננה מקבלת כל אינדיקציה על טיב הפעולה שהיא אמורה לבצע, ניתן להסיק את אחת משתי האפשרויות:

1. שהיא תבדוק בעצמה (Runtime type checking) לפי מספר הפרמטרים שסופקו
2. טיב הפעולה אינו רלוונטי עבורה

כדי לשפר את הType-Safety עבור הקוד שיעשה שימוש במתודה, ניתן לעשות שימוש בFunction Overloading:

class Instructions {
  public static operate(callback: UnaryOperation, dst: number)
  public static operate(callback: BinaryOperation, dst: number, src: number)
  public static operate(callback: SignBinaryOperation, dst: number, src: number, powerEvaluation: number)
  public static operate(callback: Function, dst: number, src?: number, powerEvaluation?: number) {
    // Note: You'll have to do type checking manually
    // here if you want differing behavior based on the required operation type
  }
}

שימוש:

operate((x) => { }, 1) // Works. Operation: Unary
operate((x, y, z) => { }, 1, 2) // Fails (x, y, z) => void' is not assignable to parameter of type 'BinaryOperation
operate((x, y, z) => { }, 1, 2, 3) // Works. Operation:  SignBinary

נ.ב. שימוש בUnion Types לא יפתור את הבעיה, משום שהסוג המדויק של OperationType לעולם לא יהיה ידוע בתוך המתודה בזמן כתיבת הקוד.

@dovid אכן System.Text.ASCIIEncoding מוגדר כקידוד הדיפולטיבי עבור SerialPort.

@צדיק-תמים כשהצהרה על משתנה קבוע היא ברירת המחדל שלך, אתה מוגן מפני שינויים שאינם רצויים (אתה מוכרח לאפשר זאת בצורה מפורשת).

@ארכיטקט timer לא בדיוק מתאים כאן.
@yossiz הבנת השימוש בAPI של Promise (כמו כן שימוש נכון במילות המפתח async-await) אינה משימה פעוטה, הקוד שצורף בשאלה לא כלל שימוש בשני המנגנונים, ולעניות דעתי (וזו הייתה כוונתי בתגובה הקודמת) אין הבדל גדול ברמות הקושי.
אני ער לעובדה שהשימוש בPromises יותר נפוץ (ונתמך בתחביר), אולם יש לזכור שמדובר במנגנון חדש יחסית שעד לפני כמה שנים השימוש בו דרש יבוא של ספרייות חיצוניות, ממש כמו השימוש בRxJs כיום.
אגב הקונספט של Observable\Observer מועמד בשנים האחרונות לשילוב בתוך השפה.

@משה-כהן345 NodeJs הוא יישום שנועד לאפשר סביבה להרצת קבצי JavaScript, היישום משתמש במנוע V8 של Chrome, השימוש העיקרי ביישום הוא עבור אפליקציות Web, אולם אתה יכול להריץ באמצעותו כל קובץ JS שתרצה.

באפשרותך להוריד את היישום מכאן.

@משה-כהן345

אני אמור להשתמש בתוסף כדי לקבל תשובה מהשרת של גיידסטאר ללא שגיאת CROS

אני לא בונה דף אינטרנט. אני צריך ליצור לולאה כדי לקבל רשימת מיילים של עמותות. (לשימוש אישי, רק זה לא רלוונטי לאסוף אותם אחד אחד מהדף של כל אחד..)

אז למה לך להריץ את הקוד בדפדפן, למה שלא תריץ את הקובץ באמצעות NodeJS?

TypeScript עדיין נחשבת לאופציה היחידה עבור פרוייקטים בינוניים ומעלה, בהם הפיתוח בJS b נחשב לקשה במיוחד\על גבול הבלתי אפשרי, מטרת המאמר שהזכרתי איננה לשלול את השימוש בTypeScript אלא לציין את מגבלותיה.

אני מצרף את הDesign Goals מתוך הWIki של TypeScript (שים לב להדגשות):
 

המטרות

1. Statically identify constructs that are likely to be errors

2. Provide a structuring mechanism for larger pieces of code

3. Impose no runtime overhead on emitted programs

4. Emit clean, idiomatic, recognizable JavaScript code

5. Produce a language that is composable and easy to reason about

6. Align with current and future ECMAScript proposals

7. Preserve runtime behavior of all JavaScript code

8. Avoid adding expression-level syntax

9. Use a consistent, fully erasable, structural type system

10. Be a cross-platform development tool

11. Do not cause substantial breaking changes from TypeScript 1.0
     

אינן המטרות

1. Exactly mimic the design of existing languages. Instead, use the behavior of JavaScript and the intentions of program authors as a guide for what makes the most sense in the language.

2. Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.

3. Apply a sound or "provably correct" type system. Instead, strike a balance between correctness and productivity.

4. Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows.

5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

6. Provide additional runtime functionality or libraries. Instead, use TypeScript to describe existing libraries.

7. Introduce behavior that is likely to surprise users. Instead have due consideration for patterns adopted by other commonly-used languages.

@yyy הפניתי את ראשי אנה ואנה לראות את מי כינית מקצוען.

@odeddvir ההצהרה על הסוג של BirthDate כDate מייצגת את התחביר של TypeScript, אשר נועדה לשפר את חויית הכתיבה, אולם בזמן הריצה אין כלל הצהרה על הסוג של הפרמטר.

@odeddvir איש #C שכמוך.

@yyy למיטב הבנתי this.DB מייצג מערך של אובייקטים שמקורם במסד נתונים כלשהו ושמכך ניתן להניח שthis.DB[i].BirthDate מייצג תאריך בפורמט JSON.
כדי לעשות שימוש במתודות שנמצאות בPrototype של Date, נדרשת תחילה המרה של התאריך שמיוצג כString לאובייקט מסוג Date.

@אבי-203 ניתן להשתמש בביטוי רגולרי התואם לתווים בUnicode שאינם כלולים בASCII, על מנת לקבוע האם מחרוזת טקסט כלשהיא מכילה תווים שאינם לטיניים:

/[^\x00-\x7F]+/.test("א")
true

/[^\x00-\x7F]+/.test("a")
false 

לחלופין ביכולתך לציין בצורה מפורשת את התווים הרצויים:

/[א-ת]+/.test("א")
true

/[א-ת]+/.test("a")
false

שימוש בביטויים הנ"ל יסתכם בחיפוש התאמה בכל רחבי הטקסט, ביכולתך כמובן לשנות את הביטוי כך שיבדוק את התו הראשון בלבד.

@yossiz אמר בהחלפת הקלדה לעברית.:

אפשר לשאול למה לא עשית convert ו-lookup סטטיים?

טעיתי לחשוב שלthis אין משמעות כלל במתודה סטטית, ומשכך הדרך להתייחס לשאר החברים הסטטיים, היא בשימוש של שמה של המחלקה.

בנוסף אולי יהיה אפשרי להסתפק רק בביטוי השני של הקוד דלהלן:

this.#lookup.get(x) ?? this.#lookup.get(x.toLowerCase())

עדכנתי את הקוד.

@yossiz
ישנם שני סיבות:

1. Scalability: הנפח של הנתונים רק הולך וגדל, ניתן להניח שבנקודת זמן כלשהי בעתיד, האפשרות לשמור את הנתונים בצורה מקומית תהיה בלתי אפשרית \ יקרה להחריד.
2. Availability: בעידן של הLoad balancing, אכסון המידע בNodes שונים, לא מאוד יעיל אם יש צורך בשליפתו.

@אבי-203 שים לב שמכיוון שTrunc מעגל לכיוון האפס, ההתנהגות עבור מספרים שליליים תהיה זהה לזו של Ceil, כלומר העיגול יתבצע כלפי מעלה.

לסיכום:

@אוריי השאלה אם אתה רוצה להשתמש עם Entity framework, או עם LinqToSql (הישן), אם מדובר בMSSQL ואין לך היכרות מוקדמת עם EF, אני ממליץ על האחרון.