مصاحبه با دمیس بلوت ، رهبر پروژه ServiceStack - قسمت 1

ServiceStack یک چارچوب خدمات وب OpenSource . NET و Mono Rest است. InfoQ این فرصت را داشت که از Demis Bellot در مورد این پروژه اطلاعاتی کسب کند. در قسمت اول این مصاحبه دو قسمتی ، ما عمدتاً در مورد انگیزه ServiceStack و گزینه های مختلف طراحی در پروژه بحث می کنیم.

InfoQ: در رویکرد مایکروسافت به خدمات چه مشکلی را مشاهده می کنید و چگونه ServiceStack سعی در مقابله با آن دارد؟

DEMIS: برخی از مشکلات مایکروسافت نتیجه ای از نگرش کلی آنها به آنچه که آنها معتقدند طراحی چارچوب خوبی را تشکیل می دهد ، برخی دیگر از عوارض جانبی در تلاش برای برآورده کردن ابزار اول طراح و تلاش برای ارائه یک API آشنا برای توسعه دهندگان به رهبری طراح است.

ارتقاء روش C# RPC خواستار طرح های API خدمات است که منجر به طراحی API های Chatty و خاص مشتری می شود

انتخاب برای استاندارد سازی در اطراف صابون شکننده ، نفخ ، آهسته و بیش از حد پیچیده و قالب های سریال WS-*

تلاش برای دستیابی به سادگی کاربر نهایی با انتزاع مصنوعی سنگین ، طراحان UI و ابزار بزرگ

ایجاد API های به شدت انتزاعی در تلاش برای ارائه توسعه دهندگان یک مدل شیء طرف سرور مصنوعی

امضاهای روش RPC

محتوای حمایت شده مرتبط

رمزگشایی میکروسرویس: کتابچه راهنمای بهترین روشها برای توسعه دهندگان

حامی مالی

Camunda 8: پیچیده ترین فرآیندهای خود را ارکستر کنید. بهره وری را با مدل سازی مشارکتی ، اتصالات خارج از جعبه و موارد دیگر بهبود بخشید. اکنون رایگان امتحان کنید.

پیگیری ارائه API RPC آشنا با ابزار UI غنی در Vs. NET (به عنوان مثال با گفتگوی "Add Service Reference") سادگی اولیه را با هزینه ترویج ضد الگوهای سرویس از راه دور معامله می کند که منجر به مسیری غیر ضروری می شود. اصطکاک و شکنندگی در دراز مدت. متأسفانه این طرح مشابه در هر چارچوب سرویس وب که مایکروسافت تولید کرده است ، ثابت شده است ، که همواره باعث ایجاد خدمات RPC خدمات API می شود که توسعه دهندگان را ترغیب به درمان خدمات از راه دور مانند تماس های روش محلی می کند. این از بسیاری جهات مضر است ، خدمات از راه دور میلیون ها بار کندتر از تماس های متد هستند که با تعریف ، وابستگی خارجی را محاصره می کنند که مستعد ابتلا به گسلها است. داشتن قرارداد خدمات ضمنی شما به امضاهای روش RPC سرور گره خورده است و قرارداد خدمات ضمنی API خود را به اجرای سرور آن نیز زوج می کند و تار می کند. عدم اجرای یک مرز به خوبی تعریف شده همان چیزی است که جدایی ضعیف از نگرانی ها و شیوه های بد بازگشت مدلهای داده سنگین ORM را از طریق سیم تشویق می کند که به دلیل ساختار رابطه ای آنها ، روابط چرخه ای با طراحی جایگزین های ضعیف برای DTO ها انجام می شود که به صورت پراکنده شکست می خورند. آنها همچنین قرارداد خدمات ضمنی شما را به مدل های داده RDBMS اساسی شما که اصطکاک را برای تغییر تغییر می دهد ، جفت می کنند. API های از راه دور همچنین از سایت های تماس سرور خود جدا شده اند که پس از استقرار پروکسی های مشتری ، همچنان در حال تکامل هستند ، چارچوب های ایده آل باید طرح های API قابل تحول و انعطاف پذیر را ارتقا دهند تا در هنگام تغییر خدمات از خرابی زمان اجرا جلوگیری کنند.

در اینجا نمونه ای از تفاوت های بین API RPC Chatty که WCF در مقابل سرویس API ServiceStack را تشویق می کند ، ارائه می دهد. در حالی که این نمونه از آموزش وب API که در ServiceStack دوباره نوشته شده است نشان می دهد که چگونه یک API مبتنی بر پیام خدمات کمتری ، کمتری و قابل استفاده مجدد را تشویق می کند.

با در آغوش گرفتن خدمات از راه دور مارتین فاولر بهترین شیوه های ServiceStack توانسته است از بسیاری از این مشکلات که در طول تاریخ توسعه دهندگان خدمات وب دات نت را به ستوه آورده اند ، جلوگیری کند:

نمای دور افتاده

استفاده از رابط های مبتنی بر پیام ، درشت دانه/دسته ای کامل را به حداقل می رساند و سفرهای دور را به حداقل می رساند و باعث ایجاد رابط های سرویس کمتر اما تحمل تر و قابل تحمل تر می شود. طراحی مبتنی بر پیام ServiceStack تضمین می کند که توسعه دهندگان همیشه طرح های API دانه ای درشت ایجاد کنند.

شیء انتقال داده (MSDN)

دیکته استفاده از POCO های با هدف خاص (اشیاء قدیمی CSHARP) برای تولید قالب سیم پاسخ خدمات وب شما. ServiceStack همواره استفاده از DTO هایی را که از اجرای آن جدا شده اند تشویق کرده و در وابستگی و مونتاژ بدون اجرای خود نگه داشته می شوند. این استراتژی همان چیزی است که اجازه می دهد تا همان نوع خدماتی که برای تعریف سرور استفاده می شود با همه مشتری های . NET که یک API تایپ شده نهایی به انتهایی را بدون استفاده از ژن کد ارائه می دهند ، به اشتراک گذاشته شود.

The Gateway (MSDN)

با محصور کردن کلیه ارتباطات سرور در پشت یک دروازه مشتری صریح و قابل استفاده مجدد. این بهترین عمل با پروکسی های ژنرال کد (مانند WCF) نقض می شود که انواع کد را با مشتری های خدمات اساسی ادغام می کند و باعث می شود که مسخره کردن ، آزمایش و جایگزینی با پیاده سازی های مختلف دشوار باشد. همچنین برای تغییر در خدمات موجود برای ایجاد خطاهای تدوین در کد مشتری معمول است. این به ندرت مسئله ای در مورد ServiceStack است که قادر به استفاده مجدد از مشتریان خدمات عمومی است ، بنابراین سطح سطح تغییر محدود به انواع است ، و به دلیل طراحی مبتنی بر پیام ما ، هرگونه عملکردی اضافه شده یا حذف شده که مورد استفاده قرار نمی گیرد ، بر مشتریان موجود تأثیر نمی گذارد.

ServiceStack الگوی دروازه را در مشتری های سرویس دهی به صورت عمومی و قابل استفاده مجدد خود تصویب می کند. ما همچنین مشتری های Silverlight ، JavaScript ، DART و حتی MQ را حفظ می کنیم. داشتن همه مشتری های سرویس دهی به اشتراک گذاشتن در رابط های یکسان ، آزمایش را آسان می کند (رهگیری یا ورود به سیستم) و همچنین قادر به جابجایی به راحتی بین هر یک از مشتری های موجود در JSON ، XML ، JSV ، MessagePack و ProToBUF بدون تغییر در کد برنامه. این امکان را فراهم می کند تا رویکرد بهینه در توسعه با یک قالب متن دوستانه با اشکال زدایی مانند JSON و سپس سوئیچ کنید تا از یکی از سریعترین بسته های پیام های باینری . NET یا ProTobuf برای حداقل بار بار و عملکرد حداکثر در ساخت استفاده کنید.

خدمات وب صابون

SOAP یکی از آن فناوری هایی است که هرگز نباید به شکل فعلی خود وجود داشته باشد ، یا حداقل در مناطقی که سود آن را ارائه می دهد ، به حاشیه رانده شود. این فرض بر این فرض ساخته شده است که برای فعال کردن داده های تبادل داده ، شما باید از پیچیدگی های انتخابی استفاده کنید ، تا حد ممکن سختگیرانه و صریح باشد و مجبور شوید همه پیاده سازی ها را برای اجرای یک طرح پیچیده به منظور برقراری ارتباط انجام دهید. در واقع برعکس اثبات شده است ، بار و پیچیدگی بسیار کمتری وجود دارد ، اگر یک قالب حداقل و انعطاف پذیر همانطور که در JSON ، CSV ، بافرهای پروتکل ، MessagePack ، BSON و غیره یافت می شود ، خروجی حاصل سریعتر ، قابل تعامل تر و قابل نسخه تر وجود دارد. واد

من همیشه تصور می کردم که علی رغم اینکه در بالای HTTP ساخته شده است ، طراحان صابون هنگام توسعه WSDL از مزایای استفاده برخوردار بودند. من انتظار دارم که توجیه چگونگی معرفی WSDL از انواع ، پیام ها ، عملیات ها ، پورت ها ، اتصالات و خدمات به نوعی جایگزینی برتر برای شناسه URL ساده HTTP و سرپرستان نوع پذیرش/محتوا دشوار باشد.

علیرغم نام آن صابون نه ساده و نه پروتکل دسترسی به شیء است و دارای خواص زیادی است که آن را به عنوان یک انتخاب ضعیف برای توسعه خدمات با ، یعنی:

این یک تناسب برنامه نویسی ضعیف است - به طور طبیعی به هر سیستم نوع شیء نقشه نمی رود که باعث ایجاد اصطکاک در هر زمان که در داخل و خارج از کد برنامه پیش بینی می شود

این HTTP را نقض می کند - HTTP شامل افعال ساده برای دسترسی توزیع شده ، به عنوان مثالGET باید بدون اثر جانبی باشد و اجازه می دهد توسط مشتری و میان افزار ذخیره شود. از آنجا که هر درخواست SOAP HTTP Post است ، قادر به استفاده از یکی از مزایای اصلی HTTP نیست

از دسترسی ضعیف برخوردار است - یک پیام SOAP در اصل یک کانتینر انتزاعی است که برای حمل و نقل اجساد بارگذاری XML و هدرهای صابون طراحی شده است. این یک رویکرد ضعیف است زیرا قالب های پیام انتزاعی نیاز به تلاش بیشتری برای دسترسی و سریال سازی در ضمن فراهم کردن دسترسی کمتر تایپ شده به داده های شما دارند. همچنین دسترسی به خدمات شما را فقط به مشتری های آگاه صابون محدود می کند. از آنجا که هیچ ارزش در دنیای واقعی ندارد ، بسیاری از API های وب دیگر در ظروف پیام پاسخ نمی دهند و به سادگی خروجی های RAW JSON و XML را به عنوان-IS سریال می کنند-روشی که به عنوان POX/J (XML قدیمی قدیمی) شناخته می شود

این پیچیده است - SOAP ، WSDLS ، UDDI ، WS-* در صورت عدم نیاز پیچیدگی های غیر ضروری را معرفی می کند. سرانجام فقط مشارکت کنندگان در مشخصات (یا توسعه دهندگان چارچوب SOAP) درک خوبی از پشته کامل WS-* و نحوه اجرای بهترین آن با چند چارچوب بزرگ آهن که سعی در اتخاذ آن دارند ، دارند.

Code-Gen را تشویق می کند-با توجه به پیچیدگی آن ، SOAP یک تلاش عموماً غیر ممکن برای اجرای بدون چارچوب SOAP و Proxies Code-Gen است

با توجه به اینکه مخالف بسیاری از مستاجران اصلی یک سرویس است ، صابون تعجب آور به همان اندازه محبوب شد. با گذشت سالها برای توسعه خدمات برای دولت ها و شرکت های بزرگ ، واقعیت ناگوار این است که برای بسیاری از آنها در معرض نقاط پایانی صابون برای خدمات خود یک الزام اجباری است. با این حال ، برای شرکت های اینترنتی و مبتدیان با ارزش ، این یک فناوری نسبتاً غیر موجود است ، در عوض بیشتر آنها تصمیم به ایجاد API های ساده HTTP دارند که پاسخ های ساده XML یا JSON را بازگردانند.

با وجود گزینه ضعیف در بیشتر موارد ، ServiceStack همچنان به فعال و پشتیبانی از نقاط پایانی صابون برای خدمات شما ادامه می دهد زیرا هنوز بسیاری از سیستم های سازمانی وجود دارد که فقط امکان اتصال به نقاط پایانی صابون را فراهم می کنند. این با اهداف اصلی ServiceStack در ارائه حداکثر ابزار ، دسترسی و دستیابی به خدمات شما هماهنگ است.

SOAP با طراحی یک فرمت بسیار شکننده و شکننده است ، جایی که به طور معمول خطاهای زمان اجرا را مشاهده می کنید اگر یک سرویس کمی از WSDL که پروکسی مشتری از آن ایجاد می شود ، منحرف شود. اگرچه شکست سریع به عنوان یک مزیت در یک سیستم استاتیک دیده می شود ، اما یک ویژگی نامطلوب برای خدمات از راه دور است که می خواهید به سازگاری به عقب و رو به جلو برسید ، بنابراین تغییرات API سرور مشتری های موجود را خراب نمی کند. این هدف توسط WCF نادیده گرفته می شود که امضاهای روش RPC ، فرمت SOAP و Code-Gen را ترویج می کند تا آنچه را که احتمالاً شکننده ترین ترکیبی از فناوری های مورد استفاده در پیاده سازی های سرویس وب است ، فراهم کند.

صابون در مقابل بافر پروتکل

جالب است بدانید که چگونه SOAP با راه حل Google برای یک بافر پروتکل IDL ساده مقایسه می شود - که تقریباً برای تمام پروتکل های داخلی RPC و قالب های پرونده خود استفاده می کند:

MessagePack RPC و Apache Thrift توسعه یافته در فیس بوک دیگر گزینه های محبوب منبع باز هستند که یک IDL سریع و ساده با الزامات برای اکثر سیستم عامل های محبوب ارائه می دهند.

با وجود توسعه توسط شرکت های مختلف ، هر یک از IDL های فوق بسیار ساده تر ، سریعتر و آسان تر استفاده از صابون که بر اساس اندازه کامل مشخصات به نظر می رسد توسط کمیته ها بدون توجه به عملکرد ، اندازه و سهولت توسعه یافته است. اجرای

با وجود اندازه و ویژگی های عملکرد برتر، Protocol Buffers و MessagePack هر دو دارای اشکال باینری بودن هستند. از آنجایی که ایجاد، نگهداری و اشکال‌زدایی آن‌ها آسان‌تر است، فرمت‌ها و پروتکل‌های مبتنی بر متن معمولاً انتخاب محبوب‌تری برای وب باز هستند. برنده واضح فرمت‌های مبادله داده‌های مبتنی بر متن در زمان‌های اخیر JSON بوده است - یک فرمت متنی ساده و جمع‌وجور که خود توصیف می‌شود که مزیت اصلی آن در دسترس بودن بومی در همه مرورگرهای دارای جاوا اسکریپت به واسطه تبدیل فوری به جاوا اسکریپت است. اشیاء با مرورگرهای داخلی عبارت "eval()". به دلیل محبوبیت آن، مرورگرهای مدرن اکنون از پشتیبانی بومی برای JSON استفاده می کنند که جایگزین امن تری برای eval() با پیاده سازی بازگشتی در جاوا اسکریپت در دسترس مرورگرهای قدیمی تر است. برای کسب اطلاعات بیشتر در مورد JSON و مزایای آن، توصیه می‌کنم سخنرانی سرگرم‌کننده Douglas Crockford's Heresy & Heretical Open Source را تماشا کنید.

به دلیل فراگیر بودن، تطبیق پذیری و سهولت اجرای آن، به صورت بومی در اکثر پلتفرم ها پشتیبانی می شود و به سرعت تبدیل به فرمت داده ترجیحی برای توسعه APIهای وب - به ویژه آنهایی که به مشتریان Ajax خدمات می دهند، می شود.

در تجربیات خودمان دریافتیم که JSON قالبی برتر برای فعال کردن خدمات است. این قالب فشرده‌تر، انعطاف‌پذیرتر، قابل تحمل‌تر و انعطاف‌پذیرتر است که ایجاد، مصرف و اشکال‌زدایی آن آسان‌تر است، اصطکاک کمتر و بهره‌وری برتر را نسبت به SOAP ارائه می‌دهد. تنها مشکل JSON در زمانی که ServiceStack را راه اندازی کردیم این بود که سریال سازهای موجود در . NET Framework در واقع کندتر از سریال کننده های XML آنها بودند. با توجه به عملکرد، از پذیرفتن این مبادله راضی نبودیم، بنابراین سریال‌ساز JSON خود را منتشر کردیم که در نهایت بیش از 3 برابر سریع‌تر از سایر سریال‌سازهای JSON. NET و بیش از 2. 5 برابر سریع‌تر از هر سریال‌ساز (از جمله باینری) بود. در دات نت فریم ورک.

با پیروی از همان روح حداقلی JSON، ما فرمت JSV را نیز توسعه داده‌ایم که مانند JSON است اما از فرار به سبک CSV استفاده می‌کند که آن را کمی سریع‌تر، فشرده‌تر و انسان‌دوستانه‌تر از JSON می‌کند. این برای سرویس‌های . NET به . NET مفید است و همچنین برای تجزیه رشته‌های Query استفاده می‌شود که در آن اجازه می‌دهد نمودارهای شی پیچیده در درخواست‌های GET در ServiceStack ارسال شود.

ServiceStack در مقابل رویکرد WCF

علی رغم اینکه چارچوب های خدمات بسیار متفاوتی در اجرای و رویکرد وجود دارد ، WCF و Servicestack اهداف نسبتاً مشابهی دارند. ServiceStack یک رویکرد بسیار سرویس گرا را در مورد خدمات ساختمان در نظر می گیرد که در آن بهینه طراحی شده است تا اجرای خدمات شما را به صورت قابل استفاده مجدد خود ضبط کند. از این طراحی کد اول ، تایپ شده ، ما قادر به استنباط هوش بیشتر از خدمات شما هستیم و به ما امکان می دهد صفحات ابرداده های XSD ، WSDL ، تولید شده توسط خودکار را تولید کنیم ، مسیرهای از پیش تعریف شده را به طور خودکار در معرض نمایش قرار دهیم. کلیه عملکردها ، ویژگی ها ، نقاط پایانی و انواع محتوای اضافه شده در اطراف مدل های موجود شما ساخته شده و بدون تلاش و تغییر در کد برنامه ، ابزار فوری را ارائه می دهند. ما از این رویکرد به عنوان شروع از مدل های کد اول به عنوان استاد کارشناسی ارشد و طرح ریزی استفاده می کنیم.

اهداف WCF همچنین ارائه یک چارچوب خدمات برای فعال کردن خدمات در چندین نقطه پایانی است اما آنها زاویه معکوس می گیرند ، و یک انتزاع یکپارچه را در تمام نقاط پایانی شبکه ارائه می دهند که شما باید خدمات خود را پیکربندی کنید. به عنوان یک هدف اصلی ، آنها همچنین یکی از معدود پیاده سازی هایی هستند که از پشته WS-* پشتیبانی عمیقی دارند.

در نهایت ما هر دو هدف ما ارائه یک چارچوب خدمات آسان برای استفاده هستیم ، ما فقط ایده های بسیار متفاوتی در مورد چگونگی دستیابی به این سادگی داریم.

سادگی و مقابله با پیچیدگی

به نظر می رسد WCF از انتزاع سنگین ، پیکربندی پیچیده XML در زمان اجرا برای مدیریت آن و ابزار بزرگ برای ارائه اتصال به پایان به پایان برای توسعه دهندگان استفاده می کند. این انتزاع بسیاری از فناوری های پیچیده را پوشش می دهد: مدل شیء انتزاعی سرور مصنوعی آن پیچیده است ، پیکربندی آن پیچیده است ، WSDL ها پیچیده هستند و SOAP / WS-* پیچیده هستند. نتیجه آن نیاز به کتابهای متنوعی در مورد هر یک از موضوعات دارد تا درک خوبی از آن داشته باشند.

انتزاع

یک مکتب فکری وجود دارد که معتقد است راه مقابله با پیچیدگی، افزودن انتزاعات سطح بالاتر است. مشکل این رویکرد این است که فقط زمانی کار می کند که انتزاع کامل باشد (مثلاً یک زبان برنامه نویسی روی کد ماشین). اگر اینطور نیست، لحظه‌ای که با رفتار یا پیکربندی غیرمنتظره‌ای مواجه می‌شوید، یکپارچه‌سازی و عملکرد متقابل، باید بفهمید که در زیر همه این لایه‌ها چه اتفاقی می‌افتد. افزودن انتزاعات بیشتر در این موارد در واقع باعث می شود توسعه دهندگان فضای مفهومی با آن آشنا باشند و سربار شناختی را که هنگام توسعه در برابر انتزاع سطح بالاتر باید بدانند افزایش می دهد. این باعث می‌شود که استدلال در مورد پایه کدتان سخت‌تر شود، زیرا باید تمام لایه‌های زیر آن را درک کنید. برای تشدید مشکل، مدل شی سمت سرور WCF جدید و مصنوعی است، توسعه‌دهندگان جدید با آن آشنا نیستند زیرا هیچ چیز دیگری مانند آن وجود ندارد و چیزی در مورد خدمات یا دامنه HTTP به شما نمی‌آموزد. بنابراین توسعه‌دهندگان وقتی به سمت چارچوب خدمات بعدی حرکت می‌کنند، هیچ انتقال دانشی به دست نمی‌آورند. به‌عنوان مثال، سرمایه‌گذاری در کتاب‌های درسی مورد نیاز برای یادگیری نحوه استفاده از WCF بهتر است برای یادگیری HTTP + TCP/IP صرف شود، زیرا هر دانشی که به دست می‌آید هنگام انتقال به سایر چارچوب‌های خدمات وب، مستقل از زبان یا پلت‌فرم، مفید باقی می‌ماند.

در پیاده‌سازی فنی، انتزاع‌های سنگین سربار عملکرد غیرضروری را متحمل می‌شوند که بهینه‌سازی آن‌ها سخت‌تر است، زیرا هنگام تلاش برای تعامل با APIهای سطح پایین، مانع ایجاد می‌کنند و اصطکاک ایجاد می‌کنند. رویکرد ما این است که انتزاع‌ها را فقط در مواقع ضروری اضافه کنیم، همانطور که در بسته‌بندی‌های نازک IHttpRequest و IHttpResponse لازم است تا یک API مشترک برای ASP. NET و میزبان‌های HttpLister خود میزبانی ارائه کنیم. به جای افزودن لایه‌های انتزاعی، ما ترجیح می‌دهیم ویژگی‌ها را به‌صورت متعامد با قرار دادن عملکرد DRY در اطراف رابط‌های سطح پایین اضافه کنیم. این مزیت اضافه‌ای دارد که به کاربران نهایی اجازه می‌دهد تا همین کار را انجام دهند و پیشرفت‌های خود را در کتابخانه‌های فضای کاربر اضافه کنند، و یک پایگاه کد ناب، خشک و خوانا را ترویج می‌کند. افشای APIهای سطح پایین تضمین می‌کند که چارچوبی انعطاف‌پذیر را حفظ کنیم که در آن کاربران کنترل کاملی بر خروجی‌های سیستم با دسترسی به چندین روش برای سفارشی‌سازی آسان پاسخ برگشتی دارند تا هرگز محدود نشوند و بتوانند هر بایتی را که بازگردانده می‌شود کنترل کنند.

انتزاعات WCF

WCF یک رویکرد منحصر به فرد به خدمات را اتخاذ می کند به این دلیل که سعی می کند تمام نقاط پایانی پشتیبانی شده را مجبور به استاندارد سازی در یک مدل انتزاع مصنوعی واحد کند. این رویکرد از عوارض جانبی از اصول کلی انتزاع رنج می برد که در آن یک مدل انتزاع یکپارچه اکنون پیچیدگی های همه چیزهایی را که در تلاش برای انتزاع است ، در نظر می گیرد ، در حالی که فقط قادر به پشتیبانی از تقاطع ویژگی ها و کمترین عملکرد مخرج مشترک موجود در هر نقطه پایانی است. واداین به یک API سطح ناقص منجر می شود ، در حالی که خود انتزاع مانع دسترسی به نقاط پایانی زیرین می شود و باعث می شود هر کدام کمتر در دسترس و قابل تنظیم باشند.

قادر به کشیدن آنچه WCF به دست آورده است ، یک شاهکار فنی عظیم به خودی خود است که نیاز به سرمایه گذاری گسترده در منابع فنی دارد. اما این در اصل یک تلاش هدر رفته است زیرا در مقایسه با رویکردهای استاندارد در سیستم عامل های جایگزین ، یک چارچوب کمتر تولیدی و قابل استفاده را در بر می گیرد. WCF همچنین برای به دست آوردن سطح تجربه ای از تجربه ، نیاز به سرمایه گذاری بسیار بیشتری از کاربران نهایی دارد. به همین دلایل ، من انتظار ندارم که ما هرگز یک چارچوب شبیه WCF یا انتزاع پایانی یکپارچه آن را که توسط هر کس دیگری انجام شده است ، ببینیم. با توجه به پیچیدگی و اندازه کافی در اجرای فنی آن ، شک دارم که با پشتیبانی از پارادایم های جدید توسعه دهنده یا الگوهای خدمات ، تکامل یابد و سازگار شود. من گمان می کنم WCF همان سرنوشت WebForms را متحمل شود که در آن به یک فناوری مستهلک منتقل می شود و به چارچوب جایگزینی Next Microsofts از دست می دهد.

ما هنوز هم قصد داریم علاوه بر بقیه ، صابون ، MQ و نقاط پایانی RCON که از قبل موجود است ، نقاط پایانی بیشتری را به ServiceStack اضافه کنیم. اما با استفاده از یک رویکرد مبتنی بر کنوانسیون ، ما از نیاز به پیکربندی سنگین خودداری می کنیم ، طراحی مبتنی بر پیام ما از ابزار بزرگ جلوگیری می کند و منطقه سطح مورد نیاز برای اجرای آن را ساده می کند ، از ایده آل C# و طرح ریزی اجازه می دهد تا عملکرد جدید به طور خودکار در دسترس باشد-کاربران ، بدون تلاش اضافی. عدم وجود یک مدل انتزاع یکپارچه و معماری جدا شده ما به ما امکان می دهد تا نقاط پایانی جدید را اضافه کنیم و ویژگی های متعامد را بدون تحمیل پیچیدگی ناعادلانه بر روی اجزای موجود اضافه کنیم.

همه ما قادر به ارائه یک چارچوب خدمات کامل ، عملکردی بهتر و بهتر ، آسان تر برای درک چارچوب خدمات در یک پایه کد بسیار لاغر و نامشخص هستیم ، که برای اجرای و حفظ نیاز به تلاش بسیار کمتری دارد.

پیکربندی سنگین

پیکربندی XML ایده دیگری است که در WCF پذیرفته شده است که ما با آن موافق نیستیم ، آزمایش را مهار می کند و برای حفظ تلاش بیشتری نیاز دارد. تنها چیزی که باید در پیکربندی برنامه های شما باشد ، بخش هایی از برنامه شما است که در واقع قابل تنظیم هستند. کد روش برتر برای تعریف و آهنگسازی وابستگی های خدمات شما باقی مانده است و این مزایا را دارد که در زمان کامپایل قابل اشکال و قابل تأیید است. WCF به بسیاری از آن نیاز دارد - ایجاد برنامه های کامل در ServiceStack که کوچکتر از اندازه پیکربندی XML WCF مورد نیاز توسط یک سرویس WCF معمولی است ، آسان است. اگر پیکربندی در سطح IOC اتفاق بیفتد - یعنی مستقیماً در برابر API . NET از ویژگی هایی که می خواهید فعال کنید ، ساده تر و تمیزتر می شود.

ابزار بزرگ

مشکل ابزار بزرگ این است که هر وقت سعی می کنید کار جدیدی را با آن انجام دهید ، یا چیزی که برای آن در نظر گرفته نشده است ، تجزیه می شود. در این موارد ، شما به یک برده به ابزار تبدیل می شوید ، محدود به ارائه قابلیت هایی که از آن پشتیبانی می کند. ابزارهای بزرگ همچنین از بازنویسی چارچوب زنده نمی مانند ، زیرا آنها پایه های کد های سنگین و پیچیده را تشویق می کنند که به سختی تکامل و فاکتور هستند. من پیش بینی می کنم این دلیل است که چرا مایکروسافت به جای اینکه بتواند موارد موجود خود را تکامل دهد ، مجبور به نوشتن مجدد چارچوب های سرویس است ، چرا WebAPI قادر به استفاده مجدد از انتزاع های موجود MVC نیست و یا پشتیبانی از صابون WCF را با وجود تصویب همان API RPC امکان پذیر نمی کند. طراحی و گزینه خود میزبانی آن که قبلاً در بالای WCF ساخته شده است.

با استفاده از انتزاع پایین ترین سطح ASP. NET به ServiceStack اجازه می دهد تا با ASP. NET MVC ادغام خوبی داشته باشد ، جایی که قادر به استفاده مجدد از پیاده سازی های موجود برای بسیاری از مؤلفه ها مانند ویژگی های فیلتر احراز هویت ، ذخیره سازی و ارائه دهندگان جلسه به راحتی در MVC است. همچنین می توانید به راحتی با خدمات ServiceStack از داخل MVC با کمی بیشتر از هزینه تماس روش C# تماس بگیرید.

Servicestack از پیچیدگی استفاده می کند

در مقابل ، Servicestack یک تصویر بسیار ساده تر است ، به عنوان مثالمعماری ServiceStack در 1 صفحه متناسب است. این فقط به 1 خط Web. config نیاز دارد تا فقط به ASP. NET بگویید تا تمام درخواست ها را به ServiceStack ارسال کند.

کنوانسیون ها و پیچیدگی های سطحی

چگونه بهتر برای مقابله با پیچیدگی احتمالاً بزرگترین تفاوت فلسفی بین رویکرد Servicestack در مقابل مایکروسافت در توسعه کتابخانه ها و چارچوب ها است. مایکروسافت ترجیح می دهد صریح و قابل تنظیم از طریق XML باشد ، انتزاع های مصنوعی سنگین جدید را معرفی می کند (به دنبال پشتیبانی از همه موارد استفاده بالقوه) ، به انتزاع متکی است تا چهره های کاربر ساده تر را در معرض نمایش قرار دهد ، بهینه سازی برای ابزار سازگار با طراح و توسعه دهندگان تازه کار. به نظر می رسد انگیزه اصلی آنها این است که یک مدل برنامه نویسی آشنا را توسعه دهند و از ابزارهای بزرگی برای تسهیل آن استفاده کنند. ما این را با WebForms مشاهده می کنیم که یک مدل برنامه ریزی مبتنی بر رویداد WinForm را برای توسعه وب سایت ها و در WCF فراهم کرده است که به توسعه دهندگان اجازه می دهد تا با استفاده از روش ها و رابط های عادی C# ، خدمات از راه دور ایجاد کنند. رویکردهای آنها به طور کلی نیاز به تلاش فنی قابل توجهی برای دستیابی به صندوق های بزرگ دارد.

در مقابل ، ما اندازه پایه کد را به عنوان بدترین دشمن کد مشاهده می کنیم و از معرفی پیچیدگی مصنوعی به عنوان یک هدف اصلی خودداری می کنیم. یعنی ما به شدت با معرفی مفاهیم جدید ، انتزاع یا مدل های برنامه نویسی مخالف هستیم. در عوض ، ما رابط های سطح پایین نازک نقشه برداری 1: 1 را با دامنه زیرین ترجیح می دهیم تا انعطاف پذیری را به حداکثر برساند ، اصطکاک را کاهش داده و پیچیدگی پیش بینی را در صورت نیاز به سفارشی سازی بیشتر به حداقل برساند. عملکرد سطح بالا و سطح بالا با استفاده از روشهای قابل استفاده مجدد و روشهای پسوند بدست می آید. اتخاذ یک مدل توسعه کد ، جوهر کاربران را در کدهای امکان پذیر کردن یک طراحی غیر سازگار با ظرافت تر ، از هرگونه پیچیدگی پیش بینی شده در هنگام رابط با ابزار طراح ، جلوگیری می کند. تمام کتابخانه های ما برای استفاده مجدد مجدد با POCO کار می کنند و مترجمان داخلی ما تلاش را در ترجمه بین مدلهای خاص دامنه ساده می کنند.

ما به کاربران یک طراحی مبتنی بر پیام بهترین عملکرد را ارائه می دهیم و از ابتدا رویکرد بهینه برای توسعه خدمات را ارتقا می بخشد. خدمات فقط کلاسهای C# معمولی هستند ، عاری از نگرانی های نقطه پایانی و وابستگی های آنها به صورت خودکار سیم کشی شده اند تا کاربران را به سمت اتخاذ کد های خوب سوق دهند.

کنوانسیون ها و کاهش دانش صنعتی بهترین سلاح ما برای مقابله با پیچیدگی است. به جای صریح بودن، بهتر است یک رفتار پیش‌فرض معمولی ارائه شود که مطابق انتظار عمل کند. این امر باعث می‌شود کاربران مجبور نباشند APIهای چارچوب‌های شما را همانطور که می‌توان در نظر گرفت، یاد بگیرند و به ما امکان می‌دهد تا عملکردهای بیشتری را به صورت رایگان ارائه دهیم، مانند فعال کردن خودکار تمام نقاط پایانی و قالب‌های داخلی ما به‌طور خودکار. شما همچنین می‌توانید هر گونه پاسخی را از خدمات خود که به صورت سریالی در نوع محتوای درخواستی ارائه می‌شود، بازگردانید.

دستیابی به سادگی

در نهایت ما معتقدیم که سادگی با اجتناب از پیچیدگی در وهله اول به بهترین وجه به دست می آید، با:

استفاده از قرارداد روی پیکربندی - همه سرویس‌هایی که IService را پیاده‌سازی می‌کنند به‌طور خودکار سیم‌کشی می‌شوند و در دسترس هستند

پیش‌فرض‌های معقول را ارائه دهید - ServiceStack فقط خارج از جعبه کار می‌کند، نیازی به پیکربندی بیشتر نیست

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

کشف خودکار - ServiceStack شامل یک صفحه / فراداده است که همه سرویس‌ها، مسیرهای موجود در آنها، XSD، WSDL و غیره را فهرست می‌کند.

هیچ ساختار مصنوعی جدیدی معرفی نکنید - توسعه دهندگان ASP. NET فوراً با نحوه سفارشی کردن درخواست و پاسخ HTTP آشنا خواهند شد.

با C# و Project out شروع کنید - با کد سی شارپ ایده آل شروع کنید و ویژگی های متعارف را اضافه کنید تا در طول توسعه عادی فوراً در دسترس باشند.

نظر به بهره وری - هر درخواست DTO در ServiceStack باید منحصر به فرد باشد، این به شما امکان می دهد هر سرویسی را فقط با نام و بدنه درخواست DTO تماس بگیرید.

ایجاد عملکرد در اطراف POCO ها - می توانید از همان POCO در ServiceStack به عنوان DTO، OrmLite Data Model، Cache، Session، Config و غیره استفاده کنید.

استفاده از طراحی مبتنی بر پیام - اتصال به یک مدل واحد بسیار ساده‌تر از امضای روش RPC برای پیاده‌سازی و توجیه آن است.

انعطاف پذیر - تعدادی فیلتر سفارشی و قلاب رویداد برای اتصال و سفارشی کردن هر مرحله از خط لوله درخواست و پاسخ ارائه کنید.

از ابزارهای بزرگ و کد ژن پرهیز کنید

ما کد ژن را دوست نداریم زیرا معتقدیم اصطکاک غیرضروری به پروژه اضافه می کند، همچنین مخالف اتکا به هر ابزار بزرگ در بخش اصلی گردش کار توسعه هستیم.

از آنجا که ServiceContract برای خدمات ServiceStack شما در طراحی درخواست و پاسخ شما با طراحی حفظ می شود ، ما می توانیم با استفاده از چیزی غیر از انواع شما برای ساختن خدمات خود و هر یک از The Generic و هر یک از برنامه های خود ، یک API تایپ شده به انتها را ارائه دهیم. قابل استفاده مجدد مشتری . NET. این امر به ما امکان می دهد API ترین ، تایپ شده و پایان به پایان از هر چارچوب خدمات در . NET ارائه دهیم.

قابلیت آزمایش

بر اساس طراحی WCF و اعتماد به نفس سنگین به پیکربندی ، به نظر نمی رسد که WCF با هرگونه آزمایش در ذهن ساخته شده است. با این حال این یک هدف اصلی در ServiceStack است ، ما به طور پیش فرض یک IOC تعبیه شده (و قابل عبور) را ارائه می دهیم و شیوه های توسعه خوب را از همان ابتدا تشویق می کنیم. خدمات فقط نیاز به اجرای رابط نشانگر IService بدون اجرای یا ارث هر یک از خدمات مناسب یا کلاس های سرویس - هر یک از آنها در انزوا و کاملاً قابل تمسخر دارند. نتیجه تلاشهای ما به همان آزمایش واحد اجازه می دهد تا به عنوان تست XML ، JSON ، JSV ، SOAP نیز خدمت کند. httplisteners خود میزبان ما باعث می شود تست های ادغام در حافظه انجام شود.

کارایی

عملکرد یک هدف اصلی در ServiceStack است زیرا ما عملکرد را مهمترین ویژگی می دانیم. طراحی مبتنی بر پیام ما تماس های شبکه کمتری را ارتقا می بخشد و ما مراقبت می کنیم که فقط API های کاربر را که سریع هستند در معرض دید قرار دهیم. مشارکتها اغلب رد می شوند زیرا حاوی کد آهسته هستند. ما در پیاده سازی های خود بی هوش هستیم ، ما از هیچ بازتاب زمان اجرا یا عبارات منظم استفاده نمی کنیم که به جای آن ترجیح می دهند از راه حل های جایگزین سریعتر استفاده کنند.

سریعترین قالبهای سریال سازی

ما سریعترین سریال سازهای متن JSON ، JSV و CSV . NET را توسعه داده و حفظ می کنیم و 2 سریال سریعترین باینری را برای بسته های دات نت و بافر پروتکل از طریق افزونه ها فعال می کنیم.

ارائه دهندگان غنی از ذخیره

از آنجا که ذخیره سازی برای ایجاد خدمات با کارایی بالا ضروری است ، ما یک مدل ارائه دهنده ذخیره سازی غنی را با اجرای برنامه های مربوط به حافظه ، Redis ، Memcached ، Azure و Amazon درج می کنیم. API های ذخیره سازی بهینه ترین فرمت ، به عنوان مثال ادامه دارند. اگر مشتری از آن پشتیبانی کند ، ما خروجی فشرده شده JSON را در حافظه نهان که مستقیماً در جریان پاسخ در درخواست های بعدی نوشته شده است ، ذخیره می کنیم و سریعترین زمان پاسخ ممکن را در کد مدیریت شده امکان پذیر می کند.

رفع مشکلات عملکرد . NET

هر زمان که گلوگاه‌ها را در کتابخانه‌های مایکروسافت شناسایی کنیم، به طور معمول آنها را با جایگزین‌هایی با عملکرد سریع‌تر جایگزین می‌کنیم. ما این کار را با Json Serializer، کتابخانه‌های Gzip و Deflate Compression قابل اتصال انجام داده‌ایم، و همچنین با ارائه پیاده‌سازی Session تمیز خودمان که با هر یک از ارائه‌دهندگان Caching فوق کار می‌کند، از مشکل عملکرد ضعیف که توسعه‌دهندگان ASP. NET را آزار می‌دهد، جلوگیری کرده‌ایم.

مشتری پیشرو برای سریعترین توزیع شده NoSQL DataStore

در جستجوی فناوری‌هایی برای توسعه خدمات با کارایی بالا، در نهایت به توسعه و نگهداری یک کلاینت پیشرو C# Redis دات‌نت برای سریع‌ترین توزیع داده NoSQL - Redis، رسیدیم.

درباره مصاحبه شونده

Demis Bellot یک توسعه دهنده در Stack Exchange است که در آنجا خدمات StackOverflow Careers 2. 0 Back Office Web & MQ را که بر روی ServiceStack ساخته شده اند، حفظ می کند. او خالق و سرپرست پروژه ServiceStack است.

توجه: قسمت دوم این مصاحبه هفته آینده منتشر خواهد شد.

از این محتوا الهام گرفته اید؟برای InfoQ بنویسید.

تبدیل شدن به یک ویرایشگر برای InfoQ یکی از بهترین تصمیمات حرفه ای من بود. این من را به چالش کشیده است و به من در بسیاری از موارد کمک کرده است که رشد کنم. ما دوست داریم افراد بیشتری به تیم ما بپیوندند.