ASP.NET MVC ზე ვიტყვი 2 სიტყვით.
ჩემის აზრით მასში არსებული არქიტექტურა არანაირ დამატებით საზრუნავს არ გიქმნის იმისათვის რომ მონაცემები, შენი სურვილისამებრ, იზოლირებული ან Shared გააკეთო.
დავიწყოთ თავიდან, ქმნი საიტს ვებ-სერვერზე (IIS) და უთითებ მას App Pool-ს. App Pool რეალურად ოპერაციული სისტემის ერთი პროცესია (w3wp.exe).
რამდენი App Pool-იც გაქვს ვებ-სერვერზე, იმავე რაოდენობის პროცესები გაქვს ოპერაციულ სისტემაშიც.
თითო საიტისთვის App Pool-ის პროცესში გამოიყოფა თითო App Domain, თუ ერთ App Pool-ში 5 საიტი გაქვს დაჰოსტილი, მაშინ შესაბამის პროცესში 5 App Domain გექნება.
ზუსტად ამ App Domain-ით ხდება ამ საიტებს შორის მეხსიერების და სხვა რესურსების იზოლირება. მაგალითად თუ ერთი საიტი დაიქრაშა, მეორე საიტს ეს არ შეეხება.
როგორც ოპერაციულ სისტემის ფარგლებში პროცესი არის იზოლირებული “ობიექტი”, იმავენაირად არის App Domain-ი პროცესის ფარგლებში.
ამის შედეგად, ყველა სტატიკური კლასი Shared იქნება ამ App Domain-ის (საიტის) ფარგლებში, ხოლო თითოეული Request ამ App Domain-ის (საიტის) მიმართ, შექმნის აპლიკაციის(HttpApplication) ახალ instance-ს.
ამ მოცემულობის გათვალისწინებით არანაირი დამატებითი კონფიგურაცია თუ პროგრამირება არ გჭირდება სასურველი ეფექტის მისაღწევად (რისი მიღწევაც არ უნდა გინდოდეს)
P.S რათქმაუნდა სხვა ქეისია Web Garden კონფიგურაცია, როდესაც ერთი და იმავე App Pool-ზე რამდენიმე პროცესის მიბმა შეგიძლია, მაგრამ ეს უკვე სხვა თემაა.
მადლობა გურამ 🙂 MVC-ზე მეც კარგი წარმოდგენის ვარ.
shared-ში იმ შემთხვევას ვგულისხმობდი როცა თვითონ ერთი აპლიკაციის ფარგლებში არის shared ნაწილი.
თუმცა მე მგონი ჯავას ფრეიმვორკებში უფრო იგრძნობა ეგ და MVC-ზე შეიძლება რო არც შეეხო მაგას.
🙂 იგივეს არა მგონი. თუ ეგეთი საქმეა, რომ უნდა გაპარალელდეს, ჩვეულებრივი php წააგებს სავარაუდოდ, რადგან მაგის multi threaded გარემოს უკიდურეს შემთხვევაში თუ გამოიყენებს კაცი. პოსტში საშუალო ზომის საიტებზე მქონდა აქცენტი გაკეთებული, სადაც ერთი რიქვესთისთვის ლოგიკის ბირთვებზე დანაწილება არ არის საჭირო.
კიდევ ერთსაც დავაკომენტარებ. ზემოთ ერკლანგი და სკალა ვახსენე და JVM ზე სკალა ძალიან მაგარია – აი რომ იყტვიან სასწაულებს და საოცრებებს ახდენსო :)))) პ.ს EE ზე რაგითხრა მაგრამ Spring ში მეტი სიმარტივე და ფლექსიბილითი გაქვს. თუ გადახედავ ზალიან მოგეწონება. ვებისთვის ჩემთვის ჯერჯერობით Angulad + Spring არის. სწრაფი, კონფორტული საშუალება.
სპრინგზე მეშინია რამის თქმა :))) ახლა ალბათ ბევრი რამე შეცვლილია, მაგრამ მე როცა ვცდილობდი მის გამოყენებას.. სამწუხაროდ ცუდი გამოცდილება უფრო ამახსოვრდება კაცს 😀 ამიტო სურვილი აღარ მქონია, რომ როდესმე მეცადა. ბევრი კარგი რამე აქვს, მაგრამ ძალიან მიჭირს ხოლმე ეგეთი რამის გამოყენება თუ ყველაფერი არ ვიცი, რასაც ჩემს გარეშე აკეთებს. რატომღაც პრობლემების ძებნაშიც კი გაცილებით მეტი დრო მეხარჯებოდა. და კომპილაცია / დაბილდვა რომ სჭირდება, ეგეც დიდი დისკომფორტი იყო ჩემთვის.
მე სტაბილურობის და უსაფრთხოების შედარება არ შემიძლია. მაგალითად php-ზე უფრო შემეშინდებოდა რამე დიდის და მნიშვნელოვანის დაწერა, ვიდრე ჯავაზე, თუმცა შეიძლება უბრალოდ სხვების სიტყვების გავლენაა.
გუშინ დილის 6 საათამდე Spring boot-ს ვარჩევდი. გადახედე, გაოგნდება ისეთია. არანაერი XML ები! ემბედით სერვერი! არც Jrebel გჭირდება, თვითნ აგვარებს რედეპლოიმენსაც. მოკლედ EE სთან შედარებით სასწაულებს ახდენს. ერთხელ რო მოვიცლი კარგ სტატიას მივუძღვნი. დაჟე მულტრი სრედინგშიც ბევრი პრობლემები გადაჭრა რაც concurrency პაკეტებს არ აქვს;
გეთანხმები ადმინ 🙂 მიჭირს რამე გამოვიყენო თუ ყველაფერი არ ვიცი. სპრინგი ძალიან დიდი და მძიმეა, ღამეები მათენებინა. ონ დემანდ ვსწავლობ ახლა, სამწუხაროდ.
მიუხედავად იმისა, რომ ჯავას მიმართ ჩემი სიყვარული საქვეყნოდაა ცნობილი, web-ის შემთხვევაში გეთანხმები, დაწერა ერთია და შიგნით რა ხდება იმის ცოდნა მეორე. ვებ კონტეინერის მუშაობა რომ გამეგო რამდენიმე წიგნი წავიკითხე, და ამის შემდეგ ვწერდი მშვიდად, იგივეს თქმა შემიძლია EE ზე. Jax-rs ის გამოყენება მირჩევნია web-ის შემთხვევაში.
ყველაზე კარგი ენაა ის რომელიც (I) დავალებას ასრულებს და (II) რომელშიც წერა გსიაამოვნებს. ზუსტად მაგ მიმდევრობით.
ემოჯები გადამიყლაპა კომენტარში! 😛 🙂
მართალი ხარ ტოტო 🙂 მეც გეთანხმები მაგაში :))
მშვენიერი პოსტია 🙂
ASP.NET MVC ზე ვიტყვი 2 სიტყვით.
ჩემის აზრით მასში არსებული არქიტექტურა არანაირ დამატებით საზრუნავს არ გიქმნის იმისათვის რომ მონაცემები, შენი სურვილისამებრ, იზოლირებული ან Shared გააკეთო.
დავიწყოთ თავიდან, ქმნი საიტს ვებ-სერვერზე (IIS) და უთითებ მას App Pool-ს. App Pool რეალურად ოპერაციული სისტემის ერთი პროცესია (w3wp.exe).
რამდენი App Pool-იც გაქვს ვებ-სერვერზე, იმავე რაოდენობის პროცესები გაქვს ოპერაციულ სისტემაშიც.
თითო საიტისთვის App Pool-ის პროცესში გამოიყოფა თითო App Domain, თუ ერთ App Pool-ში 5 საიტი გაქვს დაჰოსტილი, მაშინ შესაბამის პროცესში 5 App Domain გექნება.
ზუსტად ამ App Domain-ით ხდება ამ საიტებს შორის მეხსიერების და სხვა რესურსების იზოლირება. მაგალითად თუ ერთი საიტი დაიქრაშა, მეორე საიტს ეს არ შეეხება.
როგორც ოპერაციულ სისტემის ფარგლებში პროცესი არის იზოლირებული “ობიექტი”, იმავენაირად არის App Domain-ი პროცესის ფარგლებში.
ამის შედეგად, ყველა სტატიკური კლასი Shared იქნება ამ App Domain-ის (საიტის) ფარგლებში, ხოლო თითოეული Request ამ App Domain-ის (საიტის) მიმართ, შექმნის აპლიკაციის(HttpApplication) ახალ instance-ს.
ამ მოცემულობის გათვალისწინებით არანაირი დამატებითი კონფიგურაცია თუ პროგრამირება არ გჭირდება სასურველი ეფექტის მისაღწევად (რისი მიღწევაც არ უნდა გინდოდეს)
P.S რათქმაუნდა სხვა ქეისია Web Garden კონფიგურაცია, როდესაც ერთი და იმავე App Pool-ზე რამდენიმე პროცესის მიბმა შეგიძლია, მაგრამ ეს უკვე სხვა თემაა.
მადლობა გურამ 🙂 MVC-ზე მეც კარგი წარმოდგენის ვარ.
shared-ში იმ შემთხვევას ვგულისხმობდი როცა თვითონ ერთი აპლიკაციის ფარგლებში არის shared ნაწილი.
თუმცა მე მგონი ჯავას ფრეიმვორკებში უფრო იგრძნობა ეგ და MVC-ზე შეიძლება რო არც შეეხო მაგას.
PHP არ ვიცი. რასაც Scala და Erlang გააკეთებს , მულტისრედინგ ოპტიმიზაციაში იგივეს გაქაჩავს PHP? Async, Async, Asycnc…
🙂 იგივეს არა მგონი. თუ ეგეთი საქმეა, რომ უნდა გაპარალელდეს, ჩვეულებრივი php წააგებს სავარაუდოდ, რადგან მაგის multi threaded გარემოს უკიდურეს შემთხვევაში თუ გამოიყენებს კაცი. პოსტში საშუალო ზომის საიტებზე მქონდა აქცენტი გაკეთებული, სადაც ერთი რიქვესთისთვის ლოგიკის ბირთვებზე დანაწილება არ არის საჭირო.
100 % იანი ხარ 🙂
კიდევ ერთსაც დავაკომენტარებ. ზემოთ ერკლანგი და სკალა ვახსენე და JVM ზე სკალა ძალიან მაგარია – აი რომ იყტვიან სასწაულებს და საოცრებებს ახდენსო :)))) პ.ს EE ზე რაგითხრა მაგრამ Spring ში მეტი სიმარტივე და ფლექსიბილითი გაქვს. თუ გადახედავ ზალიან მოგეწონება. ვებისთვის ჩემთვის ჯერჯერობით Angulad + Spring არის. სწრაფი, კონფორტული საშუალება.
node.js +1. მე შორს ვარ იმ აზრისგან რო Thread-ებში ვინც ვერ ერკვევა იმას მოწონს node.js; უბრალოდ არსებობს სწორი მიდგომები რაღაც პრობლემებისთვის…
Spring-ზე რატო არ თქვი არაფერი? ერთი პარაგრაფი როგორ ვერ გაიმეტე 🙁
სპრინგზე მეშინია რამის თქმა :))) ახლა ალბათ ბევრი რამე შეცვლილია, მაგრამ მე როცა ვცდილობდი მის გამოყენებას.. სამწუხაროდ ცუდი გამოცდილება უფრო ამახსოვრდება კაცს 😀 ამიტო სურვილი აღარ მქონია, რომ როდესმე მეცადა. ბევრი კარგი რამე აქვს, მაგრამ ძალიან მიჭირს ხოლმე ეგეთი რამის გამოყენება თუ ყველაფერი არ ვიცი, რასაც ჩემს გარეშე აკეთებს. რატომღაც პრობლემების ძებნაშიც კი გაცილებით მეტი დრო მეხარჯებოდა. და კომპილაცია / დაბილდვა რომ სჭირდება, ეგეც დიდი დისკომფორტი იყო ჩემთვის.
მე სტაბილურობის და უსაფრთხოების შედარება არ შემიძლია. მაგალითად php-ზე უფრო შემეშინდებოდა რამე დიდის და მნიშვნელოვანის დაწერა, ვიდრე ჯავაზე, თუმცა შეიძლება უბრალოდ სხვების სიტყვების გავლენაა.
გუშინ დილის 6 საათამდე Spring boot-ს ვარჩევდი. გადახედე, გაოგნდება ისეთია. არანაერი XML ები! ემბედით სერვერი! არც Jrebel გჭირდება, თვითნ აგვარებს რედეპლოიმენსაც. მოკლედ EE სთან შედარებით სასწაულებს ახდენს. ერთხელ რო მოვიცლი კარგ სტატიას მივუძღვნი. დაჟე მულტრი სრედინგშიც ბევრი პრობლემები გადაჭრა რაც concurrency პაკეტებს არ აქვს;
გეთანხმები ადმინ 🙂 მიჭირს რამე გამოვიყენო თუ ყველაფერი არ ვიცი. სპრინგი ძალიან დიდი და მძიმეა, ღამეები მათენებინა. ონ დემანდ ვსწავლობ ახლა, სამწუხაროდ.
მიუხედავად იმისა, რომ ჯავას მიმართ ჩემი სიყვარული საქვეყნოდაა ცნობილი, web-ის შემთხვევაში გეთანხმები, დაწერა ერთია და შიგნით რა ხდება იმის ცოდნა მეორე. ვებ კონტეინერის მუშაობა რომ გამეგო რამდენიმე წიგნი წავიკითხე, და ამის შემდეგ ვწერდი მშვიდად, იგივეს თქმა შემიძლია EE ზე. Jax-rs ის გამოყენება მირჩევნია web-ის შემთხვევაში.