🥇پلتفرم "1C: Enterprise" - زیر کاپوت چیست؟

هی هابر!
در این مقاله ما داستان در مورد نحوه عملکرد آن در داخل را آغاز خواهیم کرد پلت فرم "1C: Enterprise 8" و از چه فناوری هایی در توسعه آن استفاده می شود.

چرا فکر می کنیم این جالب است؟ اولاً، به این دلیل که پلت فرم 1C: Enterprise 8 یک برنامه بزرگ (بیش از 10 میلیون خط کد) در C++ (کلاینت، سرور و غیره)، جاوا اسکریپت (کلینت وب) و اخیراً، و جاوه. پروژه های بزرگ حداقل به دلیل مقیاسشان می توانند جالب باشند، زیرا مسائلی که در یک پایگاه کد کوچک نامرئی هستند در چنین پروژه هایی با قدرت کامل به وجود می آیند. ثانیاً، "1C: Enterprise" یک محصول قابل تکرار و "جعبه" است و مقالات بسیار کمی در مورد چنین پیشرفت هایی در Habré وجود دارد. همچنین همیشه جالب است که بدانید زندگی در تیم ها و شرکت های دیگر چگونه است.

پس بیایید شروع کنیم. در این مقاله مروری بر برخی از فناوری‌هایی که در پلتفرم استفاده می‌شوند و چشم‌انداز را ترسیم می‌کنیم، بدون فرو رفتن عمیق در پیاده‌سازی، ارائه می‌کنیم. در واقع، برای بسیاری از مکانیسم ها، یک داستان مفصل نیاز به یک مقاله جداگانه دارد، و برای برخی، یک کتاب کامل!
برای شروع، ارزش تصمیم گیری در مورد موارد اساسی را دارد - پلت فرم 1C: Enterprise چیست و از چه اجزایی تشکیل شده است. پاسخ به این سوال چندان ساده نیست، زیرا اصطلاح "پلتفرم" (برای اختصار، آن را به این صورت می نامیم) به وسیله ای برای توسعه برنامه های کاربردی تجاری، یک محیط زمان اجرا و ابزارهای مدیریتی اشاره دارد. اجزای زیر را می توان تقریباً متمایز کرد:

خوشه سرور
کلاینت “thin” قادر به اتصال به سرور از طریق http و پروتکل باینری خود است
کلاینت برای کار در یک معماری دو لایه با یک پایگاه داده واقع در یک هارد دیسک یا پوشه شبکه
مشتری وب
ابزارهای مدیریت سرور برنامه
محیط توسعه (معروف به Configurator)
محیط اجرا برای iOS، Android و Windows Phone (پلتفرم موبایل 1C)

تمامی این قسمت ها به استثنای وب کلاینت به زبان C++ نوشته شده اند. علاوه بر این، اخیراً اعلام شده وجود دارد پیکربندی نسل جدید، نوشته شده در جاوا.

برنامه های بومی

C++03 برای توسعه برنامه های کاربردی بومی استفاده می شود. برای ویندوز، Microsoft Visual C++ 12 (نمایه ای سازگار با ویندوز XP) به عنوان کامپایلر و برای لینوکس و اندروید - gcc 4.8، برای iOS - clang 5.0 استفاده می شود. کتابخانه استاندارد مورد استفاده برای همه سیستم عامل ها و کامپایلرها یکسان است - STLPort. این راه حل احتمال خطاهای مربوط به اجرای STL را کاهش می دهد. ما در حال حاضر در حال برنامه ریزی برای مهاجرت به اجرای STL هستیم که با CLang ارسال شده است، زیرا STLPort متوقف شده است و با حالت فعال C++11 gcc ناسازگار است.
پایه کد سرور 99٪ رایج است، مشتری - 95٪. علاوه بر این، حتی پلتفرم تلفن همراه از همان کد C++ به عنوان "بزرگ" استفاده می کند، اگرچه درصد یکپارچگی در آنجا تا حدودی کمتر است.
مانند اکثر کاربران ++C، ما ادعا نمی کنیم که از 100٪ از قابلیت های زبان و کتابخانه های آن استفاده می کنیم. بنابراین، ما عملا از Boost استفاده نمی کنیم و یکی از ویژگی های زبان، ریخته گری نوع پویا است. در همان زمان، ما به طور فعال استفاده می کنیم:

STL (به ویژه رشته ها، کانتینرها و الگوریتم ها)
ارث چندگانه، از جمله وراثت پیاده سازی چندگانه
قالب ها
استثنائات
اشاره گرهای هوشمند (اجرای سفارشی)

با استفاده از وراثت چندگانه اینترفیس ها (کلاس های کاملاً انتزاعی)، یک مدل جزء امکان پذیر می شود که در ادامه به آن پرداخته خواهد شد.

اجزاء

برای اطمینان از ماژولار بودن، همه عملکردها به اجزایی تقسیم می شوند که کتابخانه های پویا هستند (*.dll برای ویندوز، *.so برای لینوکس). در مجموع بیش از صد و پنجاه جزء وجود دارد که در اینجا به شرح برخی از آنها می پردازیم:

باطن
شامل موتور فراداده پلت فرم است

acnct
اشیایی که توسعه دهندگان برنامه برای ایجاد سوابق حسابداری استفاده می کنند (نمودار حساب ها و ثبت حسابداری)

BSL
موتور اجرای زبان جاسازی شده

هسته ای
پیاده سازی سفارشی تخصیص دهنده حافظه

dbeng8
موتور پایگاه داده فایل. یک موتور پایگاه داده سرور فایل ساده مبتنی بر ISAM که شامل یک پردازنده ساده SQL نیز می شود

وب سایت
شامل کلاس ها و توابع پایه برای پیاده سازی رابط کاربری ویندوز - کلاس های پنجره، دسترسی GDI و غیره است.

تقسیم به اجزای متعدد از چند دیدگاه مفید است:

جداسازی طراحی بهتر، به ویژه جداسازی کد بهتر را ترویج می کند
از مجموعه ای از اجزا می توانید به طور انعطاف پذیر گزینه های تحویل مختلف را جمع آوری کنید:
- به عنوان مثال، نصب تین کلاینت حاوی wbase خواهد بود، اما backend نخواهد داشت
- اما در سرور wbase، برعکس، اینطور نخواهد بود
- البته هر دو گزینه حاوی nuke و bsl هستند

تمام اجزای مورد نیاز برای این گزینه راه اندازی با شروع برنامه بارگیری می شوند. این به ویژه برای ثبت کلاس های SCOM ضروری است که در زیر مورد بحث قرار خواهد گرفت.

SCOM

برای تجزیه در سطح پایین تر، از سیستم SCOM استفاده می شود، کتابخانه ای مشابه از نظر ایدئولوژی به ATL. برای کسانی که با ATL کار نکرده اند، به طور خلاصه قابلیت ها و ویژگی های اصلی را لیست می کنیم.
برای کلاس SCOM طراحی شده ویژه:

متدهای کارخانه ای را ارائه می دهد که به شما امکان می دهد کلاسی را از مؤلفه دیگری ایجاد کنید و فقط نام آن را بدانید (بدون فاش کردن پیاده سازی)
یک زیرساخت اشاره گر هوشمند با شمارش مرجع ارائه می دهد. طول عمر کلاس SCOM نیازی به نظارت دستی ندارد
به شما امکان می دهد بفهمید که آیا یک شی یک رابط خاص را پیاده سازی می کند یا خیر و به طور خودکار یک اشاره گر به شی را به یک اشاره گر به رابط تبدیل می کند.
یک شیء سرویس ایجاد کنید که همیشه از طریق متد get_service و غیره قابل دسترسی باشد.

به عنوان مثال، می توانید یک کلاس برای خواندن JSON (به عنوان مثال، JSONStreamReader) در مؤلفه json.dll توصیف کنید.
کلاس ها و نمونه ها را می توان از اجزای دیگر ایجاد کرد؛ آنها باید در ماشین SCOM ثبت شوند:

SCOM_CLASS_ENTRY(JSONStreamReader)

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

IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));

برای پشتیبانی از خدمات، SCOM یک زیرساخت اضافی و نسبتاً پیچیده ارائه می دهد. مفهوم فرآیند SCOM که به عنوان محفظه ای برای اجرای سرویس ها عمل می کند (به عنوان مثال، نقش یاب سرویس را ایفا می کند) و همچنین حاوی یک اتصال به منابع محلی است، در مرکز آن قرار دارد. فرآیند SCOM به رشته سیستم عامل گره خورده است. با تشکر از این، در داخل برنامه می توانید خدماتی مانند این را دریافت کنید:

SCOM_Process* process = core::current_process();
if (process)
         return get_service<IMyService>(process);

علاوه بر این، با تغییر فرآیندهای منطقی (SCOM) که به یک رشته گره خورده اند، می توانید برنامه هایی را دریافت کنید که عملاً از نقطه نظر فضای اطلاعات مستقل هستند و در همان رشته اجرا می شوند. تین کلاینت ما با یک پایگاه داده فایل اینگونه کار می کند - در داخل یک فرآیند سیستم عامل دو فرآیند SCOM وجود دارد، یکی با مشتری و دومی با سرور. این رویکرد به ما اجازه می دهد تا نوشتن کدی را که هم روی پایگاه داده فایل محلی و هم در نسخه مشتری-سرور «واقعی» کار می کند، یکسان کنیم. قیمت چنین یکنواختی سربار است، اما تمرین نشان می دهد که ارزش آن را دارد.

بر اساس مدل مؤلفه SCOM، هم منطق تجاری و هم بخش رابط 1C: Enterprise پیاده سازی شده است.

رابط کاربر

به هر حال، در مورد رابط ها. ما از کنترل‌های استاندارد ویندوز استفاده نمی‌کنیم، کنترل‌های ما مستقیماً بر روی Windows API پیاده‌سازی می‌شوند. برای نسخه لینوکس، یک لایه ساخته شده است که از طریق کتابخانه wxWidgets کار می کند.
کتابخانه کنترل‌ها به بخش‌های دیگر 1C:Enterprise وابسته نیست و توسط ما در چندین ابزار داخلی کوچک دیگر استفاده می‌شود.

در طول سال های توسعه 1C: Enterprise، ظاهر کنترل ها تغییر کرده است، اما تغییر جدی در اصول تنها یک بار، در سال 2009، با انتشار نسخه 8.2 و ظهور "فرم های مدیریت شده" رخ داد. علاوه بر تغییر ظاهر، اصل چیدمان فرم اساساً تغییر کرده است - موقعیت یابی پیکسل به پیکسل عناصر به نفع طرح بندی جریان عناصر رد شد. علاوه بر این، در مدل جدید، کنترل ها مستقیماً با اشیاء دامنه کار نمی کنند، بلکه با DTO های خاص (اشیاء انتقال داده).
این تغییرات ایجاد یک سرویس گیرنده وب 1C: Enterprise را امکان پذیر کرد که منطق C++ کنترل های جاوا اسکریپت را تکرار می کند. ما سعی می کنیم تا هم ارزی عملکردی را بین تین و کلاینت های وب حفظ کنیم. در مواردی که این امکان پذیر نیست، برای مثال به دلیل محدودیت های موجود در JavaScript API (به عنوان مثال، توانایی کار با فایل ها بسیار محدود است)، ما اغلب با استفاده از پسوندهای مرورگر نوشته شده در C++، عملکردهای لازم را اجرا می کنیم. ما در حال حاضر از اینترنت اکسپلورر و مایکروسافت اج (ویندوز)، گوگل کروم (ویندوز)، فایرفاکس (ویندوز و لینوکس) و سافاری (MacOS) پشتیبانی می کنیم.

علاوه بر این، از فناوری فرم های مدیریت شده برای ایجاد یک رابط برای برنامه های تلفن همراه در پلت فرم 1C استفاده می شود. در دستگاه‌های تلفن همراه، کنترل‌ها با استفاده از فناوری‌های بومی سیستم‌عامل ترسیم می‌شوند، اما برای منطق طرح‌بندی فرم و پاسخ رابط، همان کدی که در پلت‌فرم «بزرگ» 1C:Enterprise استفاده می‌شود.

رابط 1C در سیستم عامل لینوکس

رابط 1C در دستگاه تلفن همراه

رابط 1C در سیستم عامل های دیگر
رابط 1C در سیستم عامل ویندوز

رابط 1C - سرویس گیرنده وب

منبع باز

اگرچه ما از کتابخانه‌های استاندارد برای توسعه‌دهندگان C++ تحت ویندوز (MFC، کنترل‌های WinAPI) استفاده نمی‌کنیم، اما همه مؤلفه‌ها را خودمان نمی‌نویسیم. کتابخانه قبلاً ذکر شده است wx ویدجت ها، و همچنین استفاده می کنیم:

حلقه برای کار با HTTP و FTP.
OpenSSL را برای کار با رمزنگاری و ایجاد اتصالات TLS
libxml2 و libxslt برای تجزیه XML
libetpan برای کار با پروتکل های ایمیل (POP3، SMTP، IMAP)
تقلید برای تجزیه پیام های ایمیل
sqllite برای ذخیره لاگ های کاربران
ICU برای بین المللی شدن

لیست ادامه دارد.
علاوه بر این، ما از یک نسخه بسیار اصلاح شده استفاده می کنیم تست گوگل и Google Mock هنگام توسعه تست های واحد
کتابخانه ها برای سازگاری با مدل سازماندهی اجزای SCOM نیاز به تطبیق داشتند.
شیوع 1C این پلتفرم را به یک آزمون عالی قدرت برای کتابخانه های مورد استفاده در آن تبدیل می کند. انواع کاربران و سناریوها به سرعت خطاها را حتی در نادرترین قسمت های کد مورد استفاده را آشکار می کنند. ما خودمان آنها را تصحیح می کنیم و سعی می کنیم آنها را به نویسندگان کتابخانه برگردانیم. تجربه تعامل بسیار متفاوت است.
توسعه دهندگان حلقه и libetpan به‌سرعت به درخواست‌های کششی پاسخ می‌دهد، اما برای مثال، پچ در داخل است OpenSSL را ما هرگز نتوانستیم آن را پس دهیم.

نتیجه

در مقاله به چندین جنبه اصلی توسعه پلت فرم 1C: Enterprise پرداختیم. در محدوده محدود مقاله، ما فقط به برخی از جنبه های جالب، به نظر ما، اشاره کردیم.
شرح کلی مکانیسم های مختلف پلت فرم را می توان یافت اینجا.
در مقالات بعدی چه موضوعاتی برای شما جالب خواهد بود؟

پلتفرم موبایل 1C چگونه پیاده سازی می شود؟
توضیح ساختار داخلی سرویس گیرنده وب؟
یا شاید شما علاقه مند به فرآیند انتخاب ویژگی ها برای نسخه های جدید، توسعه و آزمایش هستید؟

در نظرات بنویسید!

منبع: www.habr.com

پلت فرم "1C: Enterprise" - زیر کاپوت چیست؟