مطالب
شروع کار با GraphQL در ASP.NET Core
در این مقاله هدف این است که GraphQL را در ASP.NET Core راه اندازی کنیم. از یک کتابخانه ثالث برای آسان‌تر کردن یکپارچگی استفاده می‌کنیم و همچنین با جزئیات، توضیح خواهیم داد که چگونه می‌توان از element‌های مربوط به GraphQL مثل (Type ،Query و Schema) برای کامل کردن فرآیند یکپارچگی در ASP.NET Core استفاده کنیم.

GraphQL  و تفاوت‌های آن با REST
GraphQl یک query language می‌باشد که query‌ها را با استفاده از type system‌‌‌هایی که ما برای داده‌ها تعریف می‌کنیم، اجرا می‌کند. GraphQL  به هیچ زبان یا پایگاه داده مشخصی گره نخورده است. 

  •  GraphQL نیازمند رفت و برگشت‌های کمتری به server، به منظور بازیابی داده‌ها برای template یا view است. همراه با REST ما مجبور هستیم که چندیدن endpoint مثلا  (... api/students, api/courses, api/instructors ) را برای گرفتن همه داده‌های که برای template یا view نیاز داریم ملاقات کنیم؛ ولی این شرایط در GraphQL برقرار نیست. با GraphQL ما تنها یک query را ایجاد می‌کنیم که چندین تابع (resolver) را در سمت سرور فراخوانی می‌کند و همه داده‌ها را از منابع مختلفی، در یک درخواست برگشت می‌دهد. 

  • همراه با REST، همانطور که Application ما رشد می‌کند، تعداد endpoint‌ها هم زیاد می‌شوند که این نیازمند زمان بیشتری برای نگهداری می‌باشد. اما با GraphQL ما تنها یک endpoint  داریم؛ همین! 
  • با استفاده از GraphQL، ما هرگز به مشکل گرفتن داده‌هایی کم یا زیاد از منبع روبرو نخواهیم شد. به این خاطر است که ما query‌ها را با فیلد‌هایی که چیز‌هایی را که نیاز داریم، نشان می‌دهند، تعریف می‌کنیم. در این صورت ما همیشه چیز‌هایی را که درخواست داده‌ایم، دریافت می‌کنیم.

بنابراین اگر یک query شبیه زیر را ارسال کنیم :
query OwnersQuery {
  owners {
    name
    account {
      type
    }
  } 
}
صد درصد مطمئن هستیم که خروجی زیر برگشت داده می‌شود:
{
  "data": {
    "owners": [
     {
      "name": "John Doe",
      "accounts": [
        {
          "type": "Cash"
        },
        {
          "type": "Savings"
        }
      ]
     }
    ]
  }
}

همراه با REST  این شرایط برقرار نمی‌باشد. بعضی از مواقع ما چیزی بیشتر یا کمتر از آنچه که نیاز داریم دریافت می‌کنیم؛ که این بستگی به اینکه چگونه action‌ها در یک endpoint مشخص، پیاده سازی شده‌اند، دارد.  

شروع کار 
یک پروژه جدید را با استفاده از دستور زیر ایجاد می‌کنیم: 
dotnet new api -n ASPCoreGraphQL
سپس ساختار زیر را ایجاد می‌کنیم :


پوشه Contracts شامل واسط‌های مورد نیاز برای repository logic می‌باشد:

namespace ASPCoreGraphQL.Contracts
{
    public interface IOwnerRepository
    {
    }
}
namespace ASPCoreGraphQL.Contracts
{
    public interface IAccountRepository
    {
    }
}


در پوشه Models، کلاس‌های مدل را نگه داری می‌کنیم؛ به همراه یک کلاس context و کلاس‌های configuration:
public class Owner
{
    [Key]
    public Guid Id { get; set; }
    [Required(ErrorMessage = "Name is required")]
    public string Name { get; set; }
    public string Address { get; set; }
 
    public ICollection<Account> Accounts { get; set; }
}

public class Account
{
    [Key]
    public Guid Id { get; set; }
    [Required(ErrorMessage = "Type is required")]
    public TypeOfAccount Type { get; set; }
    public string Description { get; set; }
 
    [ForeignKey("OwnerId")]
    public Guid OwnerId { get; set; }
    public Owner Owner { get; set; }
}

public enum TypeOfAccount
{
    Cash,
    Savings,
    Expense,
    Income
}
    public class ApplicationContext : DbContext
    {
        public ApplicationContext(DbContextOptions options)
            : base(options)
        {
        }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {

        }

        public DbSet<Owner> Owners { get; set; }
        public DbSet<Account> Accounts { get; set; }
    }

در پوشه Repository، کلاس‌های مرتبط با منطق بازیابی داده‌ها را داریم:
public class OwnerRepository : IOwnerRepository
{
    private readonly ApplicationContext _context;
 
    public OwnerRepository(ApplicationContext context)
    {
        _context = context;
    }
}
public class AccountRepository : IAccountRepository
{
    private readonly ApplicationContext _context;
 
    public AccountRepository(ApplicationContext context)
    {
        _context = context;
    }
}
repository logic، یک راه اندازی ابتدایی بدون هیچ لایه اضافه‌تری است.

کلاس context و کلاس‌های repository، در فایل Startup.cs ثبت می‌شوند:
public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationContext>(opt =>
         opt.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))); 
 
    services.AddScoped<IOwnerRepository, OwnerRepository>();
    services.AddScoped<IAccountRepository, AccountRepository>();
 
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2)
        .AddJsonOptions(options => options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore);
}


Integration of GraphQL in ASP.NET Core 
برای کار کردن با GraphQL در ابتدا نیاز است که کتابخانه GraphQL را نصب کنیم. به همین منظور در ترمینال مربوط به VS Code، دستور زیر را وارد می‌کنیم: 
dotnet add package GraphQL
و همچنین کتابخانه‌ی زیر که به ما کمک می‌کند تا GraphQL.NET را به عنوان یک وابستگی دریافت کنیم:
dotnet add package GraphQL.Server.Transports.AspNetCore
و در نهایت نصب کتابخانه زیر که کمک می‌کند query‌های GraphQL را به سرور ارسال کنیم:
dotnet add package GraphQL.Server.Ui.Playground

(Creating GraphQL Specific Objects (Type, Query, Schema

کار را با ایجاد کردن یک پوشه جدید به نام GraphQL و سپس در آن ایجاد یک پوشه دیگر به نام GraphQLSchema، شروع می‌کنیم. در پوشه GraphQLSchema، یک کلاس را به نام AppSchema، ایجاد می‌کنیم.
کلاس AppSchema باید از کلاس Schema ارث بری کند تا در فضای نام GraphQL.Types قرار گیرد. در سازنده این کلاس، IDependencyResolver را تزریق می‌کنیم که قرار است به ما کمک کند تا اشیاء Query ،Mutation یا Subscription را resolve کنیم:
public class AppSchema : Schema
{
    public AppSchema(IDependencyResolver resolver)
        :base(resolver)
    {
 
    }
}
چیزی که مهم است بدانیم این است که خصوصیات schema، مثل Query ،Mutation و Subscription، واسط IObjectGraphType را پیاده سازی می‌کنند تا اشیائی را که قرار است resolve کنیم، همین type را پیاده سازی کرده باشند. در ضمن GraphQL API نمی‌تواند مدل را به عنوان نتیجه به صورت مستقیم بازگشت دهد.
فعلا این کلاس را در همین حالت می‌گذاریم و سپس یک پوشه را به نام GraphQLTypes در پوشه GraphQL ایجاد می‌کنیم. در پوشه GraphQLTypes یک کلاس را به نام OwnerType ایجاد می‌کنیم:
public class OwnerType : ObjectGraphType<Owner>
{
    public OwnerType()
    {
        Field(x => x.Id, type: typeof(IdGraphType)).Description("Id property from the owner object.");
        Field(x => x.Name).Description("Name property from the owner object.");
        Field(x => x.Address).Description("Address property from the owner object.");
    }
}
از کلاس OwnerType به عنوان یک جایگزین برای مدل Owner درون یک GraphQL API استفاده می‌کنیم. این کلاس از نوع جنریک ObjectGraphType ارث بری می‌کند. با متد Field، فیلد‌هایی را که بیانگر خصوصیات مدل Owner می‌باشند، مشخص می‌کنیم.
در ابتدا واسط IOwnerRepository و کلاس  OwnerRepository را به حالت زیر ویرایش می‌کنیم:
public interface IOwnerRepository
{
    IEnumerable<Owner> GetAll();
}


public class OwnerRepository : IOwnerRepository
{
    private readonly ApplicationContext _context;
 
    public OwnerRepository(ApplicationContext context)
    {
        _context = context;
    }
 
    public IEnumerable<Owner> GetAll() => _context.Owners.ToList();
}

در ادامه یک پوشه دیگر را به نام GraphQLQueries در پوشه‌ی GraphQL ایجاد و سپس در آن یک کلاس را به نام AppQuery ایجاد و آن را به حالت زیر ویرایش می‌کنیم:
public class AppQuery : ObjectGraphType
{
    public AppQuery(IOwnerRepository repository)
    {
        Field<ListGraphType<OwnerType>>(
           "owners",
           resolve: context => repository.GetAll()
       );
    }
}

توضیحات AppQuery
همانطور که می‌بینیم این کلاس از ObjectGraphType ارث بری می‌کند. در سازنده کلاس، IOwnerRepository را تزریق می‌کنیم و یک فیلد را به منظور برگشت دادن نتیجه برای یک Query مشخص، ایجاد می‌کنیم. در این کلاس، از نوع جنریک متد Field، استفاده کرده‌ایم که تعدادی type را به عنوان یک پارامتر جنریک پذیرش می‌کند که این بیانگر GraphQL.NET برای type ‌های معمول در NET. می‌باشد. علاوه بر ListGraphType،  نوع‌هایی مثل IntGraphType  و StringGraphType و ... وجود دارند (لیست کامل).
پارامتر owners نام فیلد می‌باشد (query مربوط به کلاینت باید با این نام مطابقت داشته باشد) و پارامتر دوم نتیجه می‌باشد.
بعد از انجام این مقدمات، اکنون کلاس AppSchema  را باز می‌کنیم و به حالت زیر آن را ویرایش می‌کنیم:
public class AppSchema : Schema
{
    public AppSchema(IDependencyResolver resolver)
        :base(resolver)
    {
        Query = resolver.Resolve<AppQuery>();
    }
}

Libraries and Schema Registration 
 در کلاس Startup نیاز است کتابخانه‌های نصب شده و هم چنین  کلاس schema ایجاد شده را ثبت کنیم. این کار را با ویرایش کردن متد ConfigureServices  و Configure  انجام میدهیم:
public void ConfigureServices(IServiceCollection services)
{
    ...
 
    services.AddScoped<IDependencyResolver>(s => new FuncDependencyResolver(s.GetRequiredService));
    services.AddScoped<AppSchema>();
 
    services.AddGraphQL(o => { o.ExposeExceptions = false; })
        .AddGraphTypes(ServiceLifetime.Scoped);

   ...
}
در متد ConfigureServices، در ابتدا DependencyResolver و سپس کلاس schema را ثبت می‌کنیم. علاوه بر آن، GraphQL را با متد AddGraphQL ثبت می‌کنیم. سپس همه تایپ‌های GraphQL را با متد AddGraphTypes ثبت می‌کنیم. بدون این متد (AddGraphTypes)، ما مجبور بودیم که همه type ‌ها و query ‌ها را به صورت دستی در APIامان ثبت کنیم.
در نهایت در متد schema  Configure را به خط لوله درخواست‌ها (request’s pipeline) اضافه می‌کنیم و هم چنین ابزار Playground UI:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
   ...
    app.UseGraphQL<AppSchema>();
    app.UseGraphQLPlayground(options: new GraphQLPlaygroundOptions());
    app.UseMvc();
}

برای آزمایش GraphQL API امان، از ابزار GraphQL.UI.Playground استفاده می‌کنیم. در ابتدا پروژه را با دستور زیر اجرا می‌کنیم:
dotnet run
و سپس در مرورگر به این آدرس می‌رویم: 
https://localhost:5001/ui/playground
اکنون یک query را با نام owners ارسال می‌کنیم (این نام باید با نام query که در AppQuery در نظر گرفتیم، مطابقت داشته باشد). سپس نتیجه لازم را دریافت می‌کنیم. همانطور که مشاهده می‌کنیم، همه چیز بر اساس انتظاری که می‌رفت کار می‌کند. 



در قسمت بعد درابطه با  کوئری‌های پیشرفته، Error Handling و Data Loader در GraphQL  صحبت خواهیم کرد. 

کد‌های مربوط به این قسمت را از اینجا دریافت کنید .ASPCoreGraphQL.zip
مطالب
پیاده سازی پروژه‌های React با TypeScript - قسمت سوم - تعریف نوع رویدادها و children props
در قسمت قبل، نوع توابع ارسالی از طریق props را تعیین کردیم. فرض کنید در همان مثال می‌خواهیم بجای ارسال یک رشته به فراخوان کامپوننت تعریف شده، اصل رخ‌داد واقع شده را ارسال کنیم. به همین جهت onClick دریافتی را مستقیما به رخ‌داد onClick، نسبت می‌دهیم:
export const Button = ({ onClick }: Props) => {
  return <button onClick={onClick}>Click Me</button>;
};
در این حالت بلافاصله با خطای زیر مواجه خواهیم شد که عنوان می‌کند امضای تابع onClick، با امضای رویداد مدنظر یکی نیست:


برای رفع این مشکل، می‌توان رخ‌داد کلیک ماوس بر روی یک دکمه را از نوع بسیار عمومی React.MouseEvent تعریف کرد:
import React from "react";

type Props = {
  onClick: (e: React.MouseEvent) => void;
};

export const Button = ({ onClick }: Props) => {
  return <button onClick={onClick}>Click Me</button>;
};
پس از آن می‌توان تعریف المان کامپوننت Button را در فایل src\App.tsx به صورت زیر تغییر داد؛ چون از دیدگاه تایپ‌اسکریپت، اکنون نوع e به صورت <e: React.MouseEvent<Element, MouseEvent تعریف شده‌است و به تمام خواص و متدهای MouseEvent، با کمک intellisense کامل مرتبط با آن‌ها، دسترسی وجود دارد:
<Button
  onClick={(e) => {
    e.preventDefault();
    console.log(e);
  }}
/>


محدود کردن دامنه‌ی رویدادها


زمانیکه نوع یک رویداد به صورت کلی e: React.MouseEvent تعریف می‌شود، اگر به تصویر فوق دقت کنیم، تایپ‌اسکریپت آن‌را قابل اعمال به هر نوع Element ای می‌داند. اما اگر بخواهیم دامنه‌ی دید آن‌را صرفا به المان استاندارد button تعریف شده محدود کنیم، اشاره‌گر ماوس را در فایل src\components\Button.tsx بر روی رویداد onClick المان button تعریف شده قرار می‌دهیم:


همانطور که مشخص است، نوع این المان را به صورت HTMLButtonElement ذکر کرده‌است. بنابراین می‌توان تعریف کلی قبلی را به صورت زیر محدود کرد:
import React from "react";

type Props = {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void;
};

export const Button = ({ onClick }: Props) => {
  return <button onClick={onClick}>Click Me</button>;
};
در اینجا توسط generics، نوع React.MouseEvent به HTMLButtonElement محدود شده‌است و دیگر اینبار بازه‌ی دید آن یک Element کلی نیست. این تعریف عنوان می‌کند که رخ‌داد واقع شده، فقط از یک button صادر شده‌است و نه از المان نوع دیگری. به این ترتیب در حین استفاده‌ی از رخ‌داد رسیده در کامپوننت App در برگیرنده‌ی آن، به متدها و رخ‌دادهای ویژه‌تری نیز دسترسی خواهیم یافت.


تعیین نوع رخ‌داد onChange

در ادامه فرض کنید می‌خواهیم اطلاعات رویداد onChange را نیز صادر کنیم. روش عمومی تشخیص نوع آن، قرار دادن اشاره‌گر ماوس بر روی رویداد مدنظر و سپس استفاده از همان نوعی است که نمایش می‌دهد؛ مانند تصویر زیر:


import React from "react";

type Props = {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void;
  onChange?: (e: React.FormEvent<HTMLInputElement>) => void;
};

export const Button = ({ onClick, onChange }: Props) => {
  return (
    <>
      <input onChange={onChange} />
      <button onClick={onClick}>Click Me</button>
    </>
  );
};
در اینجا یا می‌توان از رویداد اختصاصی React.ChangeEvent از نوع HTMLInputElement، استفاده کرد و یا از حالت عمومی‌تر React.FormEvent.


سؤال: اطلاعات نمایش داده شده‌ی نوع‌های متناظر با رویدادهای مختلف در تصاویر فوق، از کجا تامین می‌شوند؟

اگر به فایل package.json پروژه‌ی تایپ‌اسکریپتی ایجاد شده مراجعه کنید، می‌توانید حداقل دو مدخل جدید زیر را نیز در آن مشاهده کنید:
{ 
  "dependencies": {
    "@types/react": "^16.9.35",
    "@types/react-dom": "^16.9.8",
  },
این بسته‌های جدید، حاوی تعاریف تمام نوع‌های تایپ‌اسکریپتی مرتبط با اشیاء یک پروژه‌ی React هستند. برای مثال در فایل src\components\Button.tsx، اشاره‌گر ماوس را بر روی MouseEvent تعریف شده قرار دهید و سپس دکمه‌ی ctrl را نگه دارید. مشاهده خواهید کرد که تعریف این نوع، تبدیل به یک لینک قابل کلیک خواهد شد. اگر بر روی آن کلیک کنید، به فایل node_modules\@types\react\index.d.ts پروژه‌ی خود هدایت می‌شوید که دقیقا محل تعریف این رویداد و موارد مشابه است.


سؤال: آیا بسته‌های @types دار موجود در فایل package.json، حجم فایل‌های نهایی برنامه را افزایش می‌دهند؟ آیا برنامه‌های React مبتنی بر TypeScript، حجم بیشتری را نسبت به نمونه‌ها‌ی ES6 آن دارند؟

اکثر این تعاریف @types به صورت اینترفیس‌های تایپ‌اسکریپتی تعریف شده‌اند که صرفا در زمان کامپایل برنامه، کمک حال کامپایلر آن خواهند بود و پس از کامپایل، تبخیر شده و در کدهای نهایی تولیدی، حضور نخواهند داشت. به عبارتی استفاده‌ی از تایپ‌اسکریپت، حجم نهایی پروژه‌ها را افزایش نمی‌دهد؛ چون اینترفیس‌های تایپ‌اسکریپت، معادلی را در جاوااسکریپت استاندارد ندارند و فقط به عنوان راهنمای کامپایلر تایپ‌اسکریپت عمل می‌کنند.


یک نکته: تعریف رویدادهای مدنظر را می‌توان در importها نیز قرار داد:
import React, { FormEvent } from "react";

type Props = {
  onChange?: (e: FormEvent<HTMLInputElement>) => void;
};
که در این حالت دیگر نیازی به ذکر کامل React.FormEvent نیست. اما در کل، روش تعریف React.xyz، مرسوم‌تر است.


تعریف نوع Children Props

زمانیکه داخل تعریف المان یک کامپوننت، کامپوننت دیگری ذکر می‌شود، به عنوان فرزند او در React درنظر گرفته می‌شود. برای نمونه تعریف کامپوننت Button را در فایل src\App.tsx به صورت زیر تغییر می‌دهیم تا فرزندی را به صورت «Hello world» بپذیرد:
<Button
  onClick={(e) => {
    e.preventDefault();
    console.log(e);
  }}
>
  Hello world!
</Button>
 اکنون سؤال اینجا است که چگونه می‌توان نوع آن‌را توسط تایپ‌اسکریپت مشخص کرد؟
با توجه به اینکه این فرزند، از نوع رشته‌ای است، فقط کافی است خاصیت children را با همین نوع، به Props اضافه کرده و از آن استفاده کنیم:
import React, { FormEvent } from "react";

type Props = {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void;
  onChange?: (e: FormEvent<HTMLInputElement>) => void;
  children: string;
};

export const Button = ({ onClick, onChange, children }: Props) => {
  return (
    <>
      <input onChange={onChange} />
      <button onClick={onClick}>{children}</button>
    </>
  );
};
در ادامه، مثال فوق را اندکی مشکل‌تر می‌کنیم. فرض کنید اینبار بجای یک رشته، یک المان image، به عنوان فرزند کامپوننت دکمه معرفی شود:
<Button
  onClick={(e) => {
    e.preventDefault();
    console.log(e);
  }}
>
  <img src={logo} className="App-logo" alt="logo" />
</Button>
که سبب بروز خطای زیر می‌شود:


عنوان می‌کند که با این تغییر، نوع children به Element تغییر یافته‌است؛ اما در تعریف Props آن، به صورت رشته‌ای معرفی شده‌است. در این حالت اگر به تعریف Props مراجعه کنیم و نوع string را به Element تغییر دهیم، باز هم این خطا برطرف نمی‌شود. حتی اگر children: HTMLImageElement را نیز اضافه کنیم، باز هم این خطا تغییری نمی‌کند.
روش صحیح حل این مشکل را در ادامه مشاهده می‌کنید:
import React, { FormEvent } from "react";

type Props = {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void;
  onChange?: (e: FormEvent<HTMLInputElement>) => void;
  // children: HTMLImageElement;
};

export const Button: React.FC<Props> = ({ onClick, onChange, children }) => {
  return (
    <>
      <input onChange={onChange} />
      <button onClick={onClick}>{children}</button>
    </>
  );
};
- ابتدا خاصیت children را از تعریف نوع Props حذف می‌کنیم.
- سپس ذکر نوع Props را هم از Object Destructuring صورت گرفته، حذف می‌کنیم.
- در آخر، نوع کامپوننت جاری را به صورت <React.FC<Props معرفی می‌کنیم. در اینجا FC یعنی Functional Component و با تعریف آن، می‌توان نوع props را به صورت آرگومان جنریک آن مشخص کرد. پس از آن دیگر نیازی به ذکر خاصیت children، در Props نیست؛ چون این خاصیت جزئی از React.FC می‌باشد و به صورت خودکار شناسایی می‌شود:



بنابراین در حالت کلی اگر از خاصیت children استفاده نمی‌کنید، از همان syntax قبلی که به صورت export const Button = ({ onClick, onChange }: Props) است، استفاده کنید؛ در غیراینصورت استفاده‌ی از نوع <React.FC<T، ضروری خواهد بود.
مطالب
استفاده از SimpleIoc به عنوان یک IoC Container
SimpleIoc به صورت پیش فرض در پروژه های  MVVM Light موجود می‌باشد. قطعه کد پایین به صورت پیش فرض در پروژه‌های MVVM Lightایجاد می‌شود.
در کلاس ViewModelLocator ما تمام میانجی(Interface)‌ها و اشیا(Objects)ی مورد نیازمان را ثبت(register) می‌کنیم.
در ادامه اجزای مختلف آن را شرح می‌دهیم. 
class ViewModelLocator
{
    static ViewModelLocator()
    {
        ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
        if (ViewModelBase.IsInDesignModeStatic)
        {
            SimpleIoc.Default.Register<IDataService, Design.DesignDataService>();
        }
        else
        {
            SimpleIoc.Default.Register<IDataService, DataService>();
        }
        SimpleIoc.Default.Register<MainViewModel>();
        SimpleIoc.Default.Register<SecondViewModel>();
    }

    public MainViewModel Main
    {
        get
        {
            return ServiceLocator.Current.GetInstance<MainViewModel>();
        }
    }
}
 
1) هر شیء که به صورت پیش فرض ایجاد می‌شود با الگوی Singlton ایجاد می‌شود.
SimpleIoc.Default.GetInstance<MainViewModel>(Guid.NewGuid().ToString());
2) جهت ثبت یک کلاس مرتبط با میانجی آن از روش زیر استفاده می‌شود.
SimpleIoc.Default.Register<IDataService, Design.DesignDataService>();
3) جهت ثبت یک شی مرتبط با میانجی از روش زیر استفاده می‌شود.
SimpleIoc.Default.Register<IDataService>(myObject);
4) جهت ثبت یک نوع (Type) به طریق زیر عمل می‌کنیم.
SimpleIoc.Default.Register<MainViewModel>();
5) جهت گرفتن وهله (Instance) از یک میانجی خاص، از روش زیر استفاده می‌کنیم.
SimpleIoc.Default.GetInstance<IDataService>();
6) جهت گرفتن وهله ای به صورت مستقیم، 'ایجاد و وضوح وابستگی(dependency resolution)' از روش زیر استفاد می‌کنیم.
SimpleIoc.Default.GetInstance();
7) برای ایجاد داده‌های زمان طراحی از روش زیر استفاده می‌کنیم.
        if (ViewModelBase.IsInDesignModeStatic)
        {
            SimpleIoc.Default.Register<IDataService, Design.DesignDataService>();
        }
        else
        {
            SimpleIoc.Default.Register<IDataService, DataService>();
        }
در حالت زمان طراحی، سرویس‌های زمان طراحی به صورت خودکار ثبت می‌شوند. و می‌توان این داده‌ها را در ViewModel‌ها و View‌ها حین طراحی مشاهده نمود.
منبع 
مطالب
WCF Method Overloading
تشریح مسئله : چگونه متد‌های سرویس WCF را Overload کنیم.

نکته : آشنایی با مفاهیم اولیه WFC برای فهم بهتر مفاهیم الزامی است.

همانطور که می‌دانیم امکان Overload کردن متد‌ها در سرویس‌های WCF وجود ندارد. یعنی نمی‌توان 2 متد با نام و پارامتر‌های متفاوت داشت. به مثال زیر دقت کنید.
ابتدا یک Contract به صورت زیر تعریف کنید
 [ServiceContract]
    public interface ISampleService
    {
        [OperationContract]
        int Sum( int number1, int number2 );

        [OperationContract]
        float Sum( float number1, float number2 );
    }
در Contract بالا دو متد با یک نام ولی آرگومان‌های متفاوت داریم. حالا یک سرویس برای این Contract می‌نویسیم.
   public class SampleService : ISampleService
    {
        public int Sum( int number1, int number2 )
        {
            return number1 + number1;
        }

        public float Sum( float number1, float number2 )
        {
            return number1 + number1;
        }
    }
اگر پروژه را کامپایل کنید پروژه بدون هیچ گونه مشکلی کامپایل خواهد شد. ولی اگر قصد استفاده از این سرویس را داشته باشیم با خطا روبرو خواهیم شد. از روش AddServiceReference استفاده کنید و سرویس مورد نظر را سمت کلاینت اضافه کنید. با خطای زیر روبرو خواهید شد.
Cannot have two operations in the same contract with the same name, 
methods Sum and Sum in type Service.ISampleService violate this rule. 
You can change the name of one of the operations by changing the method name 
or by using the Name property of OperationContractAttribute.
در این خطا به صورت کامل روش حل این مسئله گفته شده است. برای حل این مسئله باید از خاصین Name در OperationContractAttribute استفاده کرد. Contract بالا را به صورت زیر تغییر دهید.
[ServiceContract]
    public interface ISampleService
    {
        [OperationContract( Name = "SumByIntNumbers" )]
        int Sum( int number1, int number2 );

        [OperationContract( Name = "SumByFloatNumbers" )]
        float Sum( float number1, float number2 );
    }
حال اگر سرویس مورد نظر را به پروژه سمت کلاینت اضافه کنیم دو متد با نام‌های SumByIntNumbers و SumByFloatNumbers خواهیم داشت. البته اگر از روش Self Hosted استفاده کنیم دقیقا دو متد با نام Sum خواهیم داشت و Overloading را سمت سرور و کلاینت خواهیم داشت ولی در روش IIS Hosting و استفاده از AddServiceReference  از خاصیت Name برای این کار استفاده میشود.

موفق باشید.
اشتراک‌ها
سایت JS NICE
Statistical renaming, Type inference and Deobfuscation  
سایت JS NICE
اشتراک‌ها
ویژگی‌‌های OpenType
بکارگیری ویژگی‌های خاص open type برای نمایش مثلا فرمول‌ها در وب.
ویژگی‌‌های OpenType
نظرات مطالب
C# 7 - Generalized Async Return Types
«... همانطور که از نام  ValueTask نیز مشخص است، یک struct است؛ برخلاف Task  ... »
انتخاب نام Value در اینجا، به value types در دات نت اشاره می‌کند؛ اطلاعات بیشتر: