Aspnetcore: التجميعات التي تتم إزالتها من Microsoft.AspNetCore.App 3.0

أعتقد أن حزم MVC يجب أن تصبح حزم NuGet إضافية أيضًا. يعد MVC رائعًا ، ولكن على عكس Vanilla ASP.NET Core ، هناك رأي شديد في كيفية وضع تطبيق نحن والذي لا يمثل حقًا فنجانًا من الشاي للجميع ، ناهيك عن أنه يتناسب مع نموذج جميع لغات .NET. أعتقد حقًا أن إطار عمل ASP.NET Core المشترك يستحق أن يكون مجانيًا من MVC أو أن يكون لديه نسخة مجانية ثانية من MVC. ماذا تعتقد؟

ماذا ستكون الفائدة؟ كيف سيؤدي ذلك إلى تحسين حياة الأشخاص الذين يقومون بإنشاء تطبيقات ASP.NET Core؟

رائعة! أنا فقط بحاجة إلى ما أحتاجه عندما أستخدم جوهر asp.net.

تضمين التغريدة

ماذا ستكون الفائدة؟ كيف سيؤدي ذلك إلى تحسين حياة الأشخاص الذين يقومون بإنشاء تطبيقات ASP.NET Core؟

لنفس أسباب عدم تضمين الحزم المدرجة في الجزء العلوي من هذه المشكلة. أعتقد أنه من الأسهل دائمًا إضافة المزيد من الحزم إلى إطار العمل الذي سيتم شحنه مع .NET Core 3.0 بدلاً من إزالة الحزم لاحقًا. لماذا لا تبدأ في إضافة أصغر قاسم مشترك لتشغيل تطبيق Vanilla ASP.NET Core ثم تقدم الباقي كحزم NuGet. إذا تبين أن هذا يمثل مشكلة للمطورين ، فيمكنك دائمًا إضافة المزيد من الأشياء لاحقًا ، ولكن لن تتمكن من إزالة الأشياء لاحقًا بسهولة بعد الآن.

لأننا يجب أن نحقق التوازن مع كوننا مفيدًا بشكل افتراضي أيضًا.

حسنًا ، حسنًا ، أعتقد أن Vanilla ASP.NET Core مفيد بالفعل (وأعتقد أنك تعتقد ذلك أيضًا ، وإلا فلماذا لم تجعله مفيدًا؟) ، ولكن إذا كنت قد حددت بالفعل ما يجب أن يكون في إطار العمل و ما ليس فما باللك ؛)

إذا كنت شخصًا خالصًا ، فلن يكون لديك معظم البرامج الوسيطة أو MVC أو SignalR في المربع لأنها ليست ضرورية تمامًا. رسم هذا الخط الفاصل بين ما يجب أن تكون عليه المجموعة الافتراضية من الأشياء وما لا يجب أن يكون إلى حد كبير شعور داخلي وشيء غامض (بناءً على التجربة ، والنظر إلى الأنظمة الأساسية الأخرى في الماضي والحاضر وإجراء مكالمة). اعتبارًا من ASP.NET Core 3.0 ، ليس لدينا خطط لسحب هؤلاء (على الأقل في الوقت الحالي).

نعم ، أعلم أن هذه دعوة صعبة دائمًا ، لكنني في بعض الأحيان لست متأكدًا من المبرر للميل (بواسطة Microsoft) إلى تضخيم الأشياء أكثر من اللازم. الطريقة التي تضع بها منتجاتك في السوق هي كيف سيتم إدراكها. من المفترض أن يكون ASP.NET Core إطار عمل ويب جديدًا ومرنًا وقابلًا للتكوين ، ولكن الطريقة التي تحدد بها كل شيء هو أن ASP.NET Core لا فائدة منه إلا إذا فرضت MVC + SignalR + Identity + EF على الجميع. في رأيي ، لقد قمت بالفعل بالاتصال بالمكان الذي يجب رسم الخطوط فيه ، ولهذا السبب لم يتم تضمين MVC و SignalR في ASP.NET Core ولكن في إطار عمل منفصل يمكن إضافته عند الرغبة ، فلماذا تقوم بتشويش هذه الخطوط الآن؟ إنه شعور غير متسق ولا يمكنني التفكير في أي قيمة تحصل عليها منه. بدلاً من مجرد الترويج لـ ASP.NET Core + وهو نظام بيئي مزدهر مفتوح المصدر ، فأنت تروج لتجربة ويب ضيقة للغاية. كل ما يفعله هو خلق الإحباط لدى أولئك الذين يريدون أن يكونوا مختلفين قليلاً وأن يعملوا أكثر لنفسك حيث ينتهي بك الأمر إلى دفع الأشياء على الأشخاص الذين قد لا يريدون.

ليس الأمر كما لو أن الأشخاص لن يستخدموا MVC إذا لم تقم بحشوها في إطار العمل الافتراضي. اجعلها حزمة NuGet واحدة ولن يشتكي أحد من أنه يتعين عليهم الحصول على MVC من NuGet. من المرجح أن يأتي المزيد من الأشخاص ويسألون عن سبب تضخيم إطار العمل الافتراضي بأشياء لا يريدون مثلي.

أفهم أن هذه مناقشة ولا تزال شيئًا قد تفكر فيه يا رفاق ، لذلك إذا كان هناك شيء واحد أود أن تسأله هو طرح هذا السؤال مع فريقك ربما مرة أخرى ومعرفة ما إذا كنتم مستعدون حقًا لهذا الأمر أو إذا يمكنك التخفيف من فكرتي :)

ملاحظة: لست متأكدًا مما إذا كان هذا هو الحال ، لكنني آمل أن يكون SignalR عبارة عن حزمة NuGet منفصلة أيضًا. يبدو الأمر كما لو كنت تقوم بتضمين Bootstrap و Angular2 في إطار العمل الافتراضي الخاص بك. إذا تم تطوير هذين المنتجين بواسطة Microsoft ، فمن المحتمل أن تقوم بذلك ، لكن هذا لن يكون منطقيًا وأعتقد فقط لأنهما تم تنفيذهما بواسطة طرف ثالث ، فأنت ترى كيف أنه غير منطقي.

TBH أود أن أرى المزيد من الأشياء التي تمت إزالتها من التثبيت الافتراضي. خاصة MVC. هذا ما يجعل الأطر البديلة أعلى ASP.NET Core أكثر جاذبية. كما أنني أتساءل لماذا تعيش أشياء مثل ContentResult في MVC وليس في جوهرها. يتم استخدامه كثيرًا في الوظائف اللازوردية والآن يتعين علي دائمًا الرجوع إلى عناصر MVC - فقط من أجل ContentResult.

أعتقد أن النقطة المهمة هي أنه لا ينبغي أن يؤثر ذلك سلبًا على وجود عناصر MVC في ASPNET SDK. سيستخدمه معظم المطورين ، لذا يفضل شحنه بهذه الطريقة على تحميل استعادة الانتفاخ. إذا كنت لا تريده ، فلا يمكنك استخدامه. تجلب معظم الحزم المذكورة أعلاه تبعيات لجهات خارجية (json) ، أو لها بعض الجوانب الثقيلة (الشفرة) ، أو منفصلة من الناحية المفاهيمية عن ASPNET وغالبًا ما يشار إليها خارج SDK (EFCore).

وبقدر ما أتفق مع التقصير في الحد الأدنى لتعزيز ساحة لعب متساوية لأطر البرمجيات مفتوحة المصدر ، يجب أن يكون ذلك متوازنًا. في الأيام الأولى من Core (بيتا وحتى 1.0) ، كانت الأشياء عبارة عن حزم في كل مكان وكان هذا الأمر أكثر إرباكًا واستغرق الاستعادة إلى الأبد.

psibernetic حتى لو كانت الأشياء في حزم منفصلة ، يمكن لبرنامج التثبيت الأساسي net وضع هذه الحزم بالفعل في ذاكرة التخزين المؤقت المحلية.

psibernetic أنت الشخص الثاني الذي يذكر أنه من المهم تحقيق التوازن ، ولكن ماذا يعني ذلك؟ التوازن بين ماذا؟ دعونا لا نتحدث عن التطرف ، لأنه من الواضح أن هذا ليس جيدًا ، فلنتحدث عن مقترحات واقعية هنا. إذا كانت MVC عبارة عن حزمة NuGet واحدة ، فبأي طريقة تؤثر على قابلية الاستخدام؟ إنها حقًا ليست كذلك وهذه وجهة نظري. التفكير في أنك ستحل طرفًا متطرفًا من خلال تنفيذ النقيض المعاكس هو التفكير الضيق. هناك الكثير في المنتصف. لا يجب أن يكون إطار العمل منتفخًا ولا يجب تجزئة MVC و SignalR إلى 100 حزمة أيضًا. يمكن تجنب كليهما في نفس الوقت.

أعطني حالة واحدة في العالم الحقيقي حيث سيكون وجود MVC كحزمة NuGet واحدة مربكًا ، أو أن الاستعادة ستستغرق إلى الأبد ، أو أي من السلبيات الأخرى التي ذكرتها؟

والحديث عن استعادة الوقت ...

IMHO من الأهمية بمكان أن يكون لديك حاويات سريعة البدء أو بنية بدون خادم (لأن هذا ما له تأثير حقيقي على الأعمال التجارية) من وجود بنية أسرع قليلاً على جهاز مطور. نعم ، هذا الأخير مهم للغاية أيضًا وأريد أن يكون سريعًا للغاية ، ولكن إذا كان عليّ تصنيف الأهمية ، فأنا أفضل أن أحصل على نتيجة بسيطة على جهاز التطوير الخاص بي بدلاً من البنية التحتية للإنتاج الخاصة بي في السحابة. لذا فإن الحفاظ على المساحة صغيرة قدر الإمكان (إن لم يكن أكثر) مهم فقط من الحفاظ على وقت الاستعادة.

ماذا ستكون الفائدة؟ كيف سيؤدي ذلك إلى تحسين حياة الأشخاص الذين يقومون بإنشاء تطبيقات ASP.NET Core؟

أعتقد أنه برنامج bloatware غير مرغوب فيه لجميع المستخدمين الآخرين الذين لا يستخدمون MVC ، مثل CandyCrush المثبت مسبقًا على جهاز الكمبيوتر الذي يعمل بنظام Windows 10. نادى Asp.net core أنه أصبح أقل إبداءً للرأي مع إمكانية تكوينه بالكامل ، حسب الحاجة إلى البرامج الوسيطة وما إلى ذلك. تسمح قوالب dotnet لـ MVC أن تكون حزمة مضمنة افتراضية دون الحاجة إلى تحويلها إلى نواة؟

هناك العديد من الأطر الأخرى مثل Nancy و ServiceStack و Giraffe وجميعها لها مزاياها ولا ينبغي أن يكون لها انتفاخ / تضارب مع تثبيت MVC غير مرغوب فيه / غير ضروري. يبدو أنه غير متسق نظرًا لأن المصادقة والشفرات و EF إلخ كلها مغلفة ولكن MVC ، الطفل الذهبي يجب أن يكون جزءًا من إطار العمل الأساسي عندما لا يكون أساسيًا؟

إذا كان ذلك بسبب اقتران MVC بشدة بالجوهر ، فإن الفصل سيكون بمثابة الكثير من العمل ، يمكنني الحصول على ذلك ، ولكن على أساس أنه يجعل حياة بعض المطورين أسهل بشكل عام ، يبدو كسولًا ويشبه إلى حد كبير شبكة asp.net القديمة عقلية MVC كنت آمل أن نبتعد عنها.

كان من المفترض أن يكون .NET Core هو الاستنساخ المعياري البسيط لـ node.js لـ .NET ولكن لا يبدو أنه لديه أي نية لتكرار الخصائص التي تعزز نظامه البيئي المزدهر والنابض بالحياة - وهو نواة صغيرة ومرنة غير معلن عنها مع ميزات مضمنة في جوهرها ، فإن الاستفادة من كل ذلك بفضل عدم التضمين في أي إطار ويب معني بآرائه ، قد حان للتجربة التي تتمتع بعدد صحي من الأطر الشائعة مع مجتمعاتهم المستقلة.

أعني أن فريق ASP.NET يعتقد أنهم ينشئون أفضل إطار عمل ممكن ، ولكن لا يتفق الجميع مع جميع الآراء التي يتم اختيارها أو مستوى التعقيد المطلوب لإنجاز شيء ما. تم تطوير كل شيء في .NET Core بالاستفادة من الإدراك المتأخر مع الكثير من الإلهام بالطرق التي شوهدت أصبحت ناجحة على الأنظمة الأساسية الأخرى ، من خلال التعمق في الآراء حول التقنيات التي يجب استخدامها ، فأنت تتضور جوعًا للابتكار التالي القادم من .NET وحتى عندما يكتسب الشيء التالي قوة دفع على الأنظمة الأساسية الأخرى ، سيكون ASP.NET Core في وضع غير موات لتكرار نجاحه لأننا سنقوم إلى الأبد بدفع "ضريبة MVC" الافتراضية للمضي قدمًا حيث من المتوقع أن يستخدم الجميع نموذج التطوير الخاص به لجميع مواقع الويب التطبيقات الإعلانية اللانهائية.

كما أن خفة وزن Node يجعلها مناسبة أيضًا لتطوير عدد من حالات الاستخدام الأخرى مثل Electron و Native Mobile Apps و IOT و shell scripts وما إلى ذلك ، أي لا يستفيد أي منها من وجود إطار عمل للويب مجمّع في التثبيت الافتراضي. كلما زاد تضخم التثبيت الافتراضي ، أصبح التثبيت الافتراضي أقل فائدة للاستخدام في السيناريوهات الأخرى.

يجب أن تعود IMO الافتراضي إلى الرؤية الأصلية لـ .NET Core المتمثلة في امتلاك نواة معيارية بسيطة مع التركيز على تسهيل إضافة الميزات (التي يمكن للجميع الاستفادة منها) ، أي ليس عن طريق تجميعها افتراضيًا وتضخيم الوضع الافتراضي تثبيت.

شكرا لك على ملاحظاتك. اسمحوا لي أن أشارككم بعض الأفكار.

1. نحن لا نقوم بقص التجمعات لأننا نشعر بذلك. كل مجموعة نزيلها هي تغيير جذري وتضيف إلى تكلفة الترقية من 2.x إلى 3.0. هذه هي المبادئ التوجيهية التي نستخدمها لاتخاذ قرار بشأن ما يدخل في Microsoft.AspNetCore.App: https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. التجميعات التي نقترح إزالتها تفتقد إلى بعض معايير التضمين في إطار العمل المشترك. والجدير بالذكر أن هذه التجميعات إما: (1) لها تبعيات على كود طرف ثالث ليس لدينا القدرة على خدمة (2) التجميعات نفسها تم إهمالها في 3.0 أو (3) أنها تنفذ بروتوكولات أو آلية مصادقة تخضع بشدة للتغيير ( على سبيل المثال ، قد يقرر Facebook / Google / Twitter تغيير طريقة عمل المصادقة غدًا)

2. إزالة MVC من Microsoft.AspNetCore.App ليس شيئًا نعتبره. على الرغم من أننا لا ندرك أن كل مستخدم يشير إلى MVC في تطبيقه ، إلا أننا نعتقد أن هذا جزء أساسي من عروض ASP.NET Core. نحن نخطط للإبقاء على هذا في Microsoft.AspNetCore.App.

3. لقد كان MVC جزءًا من Microsoft.AspNetCore.App منذ 2.1 ، ولكن كما سترى في قوالب 2.1 "Empty Web" ، لا يتعين عليك استخدام MVC. إن وجوده في إطار العمل المشترك لا يجبرك على استخدامه في تطبيقك. لا يزال بإمكانك استخدام البدائل ، أو كتابة إطار عمل العرض الخاص بك ، أو استخدام واجهات برمجة تطبيقات aspnetcore "الأولية" لقراءة طلبات واستجابات HTTP وكتابتها مباشرة.

4. @ dustinmoris : أعتقد أنه من الأسهل دائمًا إضافة المزيد من الحزم إلى الإطار الذي سيتم شحنه مع .NET Core 3.0 بدلاً من إزالة الحزم لاحقًا. لماذا لا تبدأ في إضافة أصغر قاسم مشترك لتشغيل تطبيق Vanilla ASP.NET Core ثم تقدم الباقي كحزم NuGet. إذا تبين أن هذا يمثل مشكلة للمطورين ، فيمكنك دائمًا إضافة المزيد من الأشياء لاحقًا ، ولكن لن تتمكن من إزالة الأشياء لاحقًا بسهولة بعد الآن.

   هذا هو بالضبط ما نحاول القيام به. من الأسهل الإضافة من الإزالة. لقد أضفنا الكثير من الأشياء في الإصدار 2.0 ، ونقوم بإعادة ضبط ما نعتقد أنه مجموعة من الأشياء يمكن صيانتها للطريق المتوقع في المستقبل. سيستمر تقديم معظم التجميعات التي تمت إزالتها من Microsoft.AspNetCore.App كحزم NuGet. إذا وجدنا لاحقًا أن 90٪ من العملاء يشيرون إلى نفس الحزمة ، فهذا مرشح جيد للإطار المشترك. ومع ذلك ، كما هو مذكور في مستند التوجيه ، فإن مقدار استخدام واجهة برمجة التطبيقات يعد مقياسًا مهمًا ، ولكنه ليس العامل الوحيد الذي نضعه في الاعتبار.

5. "الفانيليا" شخصية. بالنسبة للعديد من مستخدمينا ، فإن MVC و SignalR هما "الفانيليا".

6. قال عدد قليل من الناس أن NET Core كان من المفترض أن يكون هذا أو ذاك أو شيء آخر. تتغير الأشياء ، ونجمع تعليقات المستخدمين ، ونلاحظ كيفية استخدام المنتج ، ونحاول تعديل الإعدادات الافتراضية لتتناسب مع ما نعتقد أنه سيفيد أكبر عدد من العملاء. التعديلات المقترحة في هذه المشكلة هي انعكاس للتعليقات التي تلقيناها على .NET Core 2.x.

الفكرة الأخيرة: هذه القضية لن تجعل الجميع سعداء. إذا بدا الأمر كما لو أننا نتجاهل ملاحظاتك ، فأنا أعتذر. يُرجى إدراك أن لدينا مئات الآلاف من العملاء ، وأن عددًا قليلاً منهم فقط يأتون إلى GitHub لمشاركة التعليقات. نقوم أيضًا بجمع المعلومات من الزيارات الشخصية والمكالمات الهاتفية ورسائل البريد الإلكتروني ووسائل التواصل الاجتماعي وطلبات دعم العملاء والمدونات والقياس عن بُعد في Visual Studio والمزيد. كل هذا جزء مما نعتبره عندما نتخذ القرارات وما هو جزء من التجربة الافتراضية وما هو ليس كذلك.

إذا كان هناك شيء غير واضح حول دوافعنا أو أسبابنا ، فيرجى إبلاغي بذلك وسأحاول التوضيح.

إذا كان لديك الكثير من الاتصال المباشر مع العملاء ، فمتى كانت آخر مرة سألت فيها عن عدد المستخدمين الذين يستخدمون MVC و SignalR؟ هل هناك مقاييس استخدام حقيقية وراء هذا الموقف وهي الاحتفاظ بها بالتأكيد بدلاً من وجود كل منها في حزمة NuGet واحدة يمكن تثبيتها بسهولة عند الحاجة؟

dustinmoris بما في ذلك MVC في وقت التشغيل المشترك يعني أنه تم شحنه

كل ذلك قيل ، واعلم أنه ليس لدي أي انتماء مع Microsoft أو فريق aspnet ، يمكن أن أرى وقت تشغيل منفصل تم شحنه والذي كان عبارة عن أداة aspnetcore مجردة إذا نطق المجتمع بها حقًا وأثبت أنها كانت رغبة كبيرة. تقدم المهمة تجربة رائعة لأكبر عدد ممكن من التطبيقات والمطورين ، والحقيقة في الوقت الحالي هي نسبة عالية بشكل لا يصدق من أولئك الذين يستفيدون من MVC في وقت التشغيل المشترك. natemcmaster هل هناك طريقة مفضلة للأفراد المعنيين للتصويت لهذا في المستقبل ، ربما قضية جيثب ، وهل هذا حل معقول؟

psibernetic ، نرحب ببدء مشكلة GitHub جديدة لإزالة MVC من إطار العمل المشترك ، ولكن كما ذكرت أعلاه ، فإن إزالة MVC من Microsoft.AspNetCore.App ليس شيئًا نفكر فيه ، لذلك من غير المرجح أن تكتسب هذه المشكلة قوة جذب داخل فريقنا.

Bomret تقريبًا كل تطبيق عميل في العالم الحقيقي

Natemcmaster : أنا على هاتفي الآن ، ولكن شكرا على الشرح وأنا فقط
أدركت أن هذا يتعلق بالمجموعة الوصفية بينما كنت أتحدث عن
إطار مشترك.

natemcmaster أعتقد أن forki و @ dustinmorris و mythz قد ذكروا أسبابًا

إنه يسمى "Microsoft.AspNetCore.App" ، فلماذا لا تنشئ واحدًا آخر "Microsoft.AspNetCoreMVC.App"؟

على أي حال ، أنا أفهم أنه من الصعب جدًا رسم الخط ، ولكن أعتقد أن التعليقات العامة هنا هي أن لديك عددًا متزايدًا من الأشخاص الذين يحبون ما فعلته مع aspnet core ، لكن من لا يحب حقًا أشياء مثل MVC ، ماكينة الحلاقة ، EF أو signalR.

في الواقع. يمكنك الاعتماد على المجتمع ليكون نابضًا بالحيوية بما يكفي لإحضار الكثير من الأفكار عن libs والأطر للتعامل مع واجهة برمجة التطبيقات والويب ومنافذ الويب والقوالب والوصول إلى db وما إلى ذلك. ستقدمون يا رفاق خيارًا واحدًا لمن لديهم MVC و Razor و EF وما إلى ذلك ولكن ليس الخيار الوحيد أو الافتراضي.

natemcmaster خطأي ، كنت أتحدث بالفعل عن إطار العمل المشترك في هذه المسألة هنا. أعتقد أن نفس الأسباب تنطبق أيضًا على الحزمة الوصفية ، ولكن لكي أكون صادقًا ، فأنا أقل قلقًا بشأن ذلك ، لأنني أستطيع بالفعل الإشارة إلى الحزم الفردية بدلاً من الحزمة الوصفية ، لكن لا يمكنني بسهولة تقليص إطار عمل مشترك إذا أردت الاحتفاظ به حاوية صغيرة قدر الإمكان ، لذا فإن اقتراحك بفتح مشكلة جديدة لإطار العمل المشترك منطقي 👍

natemcmaster هل يمكنك التأكيد بسرعة إذا فهمت الأشياء بشكل صحيح:

• سيكون هناك إطار عمل ASP.NET Core مشترك مدمج في وقت تشغيل .NET Core التالي (3.0) ، مما يعني أنه يتم شحن ASP.NET Core كجزء من تثبيت .NET Core في بيئة ما.

• بالإضافة إلى ذلك ، هناك حزمة وصفية تسمى Microsoft.AspNetCore.App و Microsoft.AspNetCore.All وهي مجموعة من حزم NuGet لتطبيقات ASP.NET Core

• إطار عمل ASP.NET الأساسي المشترك <الحزمة الوصفية Microsoft.AspNetCore.App التي تتضمن أشياء مثل EF Core؟

• يمكنني إنشاء تطبيق ويب ASP.NET Core دون الحاجة إلى تضمين الحزمة الوصفية Microsoft.AspNetCore.App التي تحتوي على EF Core و SignalR و MVC وما إلى ذلك إذا كنت أرغب فقط في إنشاء واجهة برمجة تطبيقات صغيرة للغاية؟

• مهما كان ما تفعلونه يا رفاق ، سيكون من الممكن إنشاء حاوية Docker مع الحد الأدنى فقط من التبعيات لـ ASP.NET Core من أجل تشغيل واجهة برمجة تطبيقات صغيرة؟

سيكون هناك إطار عمل ASP.NET Core مشترك مدمج في وقت تشغيل .NET Core التالي (3.0) ، مما يعني أنه يتم شحن ASP.NET Core كجزء من تثبيت .NET Core في بيئة ما.

نعم

بالإضافة إلى ذلك ، هناك حزمة تعريفية تسمى Microsoft.AspNetCore.App و Microsoft.AspNetCore ، وكلها مجموعة من حزم NuGet لتطبيقات ASP.NET Core

لا ، هناك مفهوم جديد يسمى FrameworkReference و Microsoft.AspNetCore.App سيكون واحدًا من هؤلاء. Microsoft.AspNetCore.All لن يكون موجودًا في 3.0.

إطار عمل ASP.NET Core المشترك <الحزمة الوصفية Microsoft.AspNetCore.App التي تتضمن أشياء مثل EF Core؟

لا ، لا يشمل EF.

مهما كان ما تفعلونه يا رفاق ، سيكون من الممكن إنشاء حاوية Docker مع الحد الأدنى فقط من التبعيات لـ ASP.NET Core من أجل تشغيل واجهة برمجة تطبيقات صغيرة؟

مع تقليم التجميع والرابط نعم ، ليس عن طريق إزالة الحزم لأنه لن يكون هناك أي لـ ASP.NET Core.

تضمين التغريدة

نحن لا نقوم بقص التجمعات لأننا نشعر بذلك. كل مجموعة نزيلها هي تغيير جذري وتضيف إلى تكلفة الترقية من 2.x إلى 3.0.

المكان المناسب لإجراء أي تصحيحات سيكون ضمن نافذة الإصدار الرئيسي v3 وهو فعليًا الوقت الوحيد الذي يمكن أن تحدث فيه تغييرات مثل هذه ، أي في نفس الوقت الذي تتم فيه إزالة الحزم الأخرى.

إزالة MVC من Microsoft.AspNetCore.App ليس شيئًا نعتبره. على الرغم من أننا ندرك أنه لا يشير كل مستخدم إلى MVC في تطبيقه.

يطلق عليه "Microsoft.AspNetCore.App" والذي يقرأ منطقيًا على أنه "مرجع هذه الحزمة" إذا كنت تقوم بإنشاء "تطبيق ASP.NET Core".

نعتقد أن هذا جزء أساسي من عرض ASP.NET Core. نحن نخطط للإبقاء على هذا في Microsoft.AspNetCore.App.

يقترب هذا من جوهر المشكلة حيث يبدو أن أهداف ASP.NET Core تتحرك بعيدًا عن تعزيز نظام بيئي بسيط ومفتوح لنمط node.js-esque. هل نية الفريق للجميع دمج تطبيقات ASP.NET الأساسية كمرادف لتطبيقات MVC؟ كانت بعض نقاط البيع في ASP.NET Core هي "الدفع للتشغيل" وفصل "الطبقات" ولكن هذا يشير إلى أن "تطبيق ASP.NET Core" يهدف إلى الأبد إلى = MVC App.

سيكون الأمر أكثر وضوحًا لجميع المعنيين إذا كانت الحزم أكثر وضوحًا حيث:

• Microsoft.AspNetCore.App => قاعدة لجميع تطبيقات ASP.NET الأساسية
• Microsoft.AspNetCore.Mvc => تطبيق ASP.NET Core MVC

ولكن إذا كان "Microsoft.AspNetCore.App" لا يمكن المساس به ، فهل يمكننا على الأقل الحصول على حزمة تعريف رسمية "أساسية للسطر" (أو FrameworkReference) مع ميزات الخادم الأساسية فقط (أي بدون أي تحريرات معبرة) ، وبعض الأسماء المحتملة:

• Microsoft.AspNetCore. [قاعدة | عارية | لايت | أساسي]

(كان من الممكن أيضًا أن يكون "Core" مناسبًا ولكن هناك بالفعل استخدام مفرط للمصطلح).

بدون وجود حزمة وصفية رسمية / اسم ، لن يكون الوصول إليها كما هو موصى به حاليًا "Microsoft.AspNetCore.App" وهذا هو الأساس الموصى به لجميع تطبيقات ASP.NET الأساسية.

تولد القيود الابتكار حيث إذا كان بإمكان MVC العمل فقط في نفس ميدان اللعب مثل أي شخص آخر ، فربما يمكننا جميعًا الوصول إلى ميزة تتيح لنا بسهولة وصراحة الإعلان عن المنتجات (المعروفة أيضًا باسم مجموعة الحزم) التي تحتاجها التطبيقات ، على سبيل المثال يمكن أن تبدو شيئًا ما مثل:

• Microsoft.AspNetCore.Mvc + SignalR + EF

حيث يمكن للجميع بسهولة التصريح عن ما يحتاجون إليه وتثبيته فقط والأدوات الموجودة في الكواليس يمكن أن تجمع بين حزم التعريف "Microsoft.AspNetCore.Mvc" و "Microsoft.AspNetCore.SignalR" و "Microsoft.AspNetCore.EF". (أو بديل حل متفوق لتحقيق النية).

إن وجوده في إطار العمل المشترك لا يجبرك على استخدامه في تطبيقك.

يبدو وكأنه الأساس المنطقي لكل متراصة تم إنشاؤها على الإطلاق. "لا يتعين عليك استخدام كل ما نجمعه ، إنه موجود فقط من أجل راحتك".

لا يزال بإمكانك استخدام البدائل ، اكتب إطار العرض الخاص بك ،

إنه ليس مرحبًا كما تعتقد ، على سبيل المثال بينما كنا نطور "إطار عرض" خاص بنا بديلاً لـ MVC و Razor ، واجهنا سلوكًا سحريًا في .NET Core حيث يفشل البناء عند تشغيل الأمر القياسي لنشر ملف. مشروع NET Core ، على سبيل المثال:

 dotnet publish -c Release

والتي ستفشل مع:

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

سلوك مفاجئ نظرًا لأننا كنا نطور بديلاً لـ MVC والذي لم يشير صراحةً إلى MVC أو Razor أو يتضمن أي صفحات .cshtml نظرًا لأن الغرض منه كان إنشاء تطبيقات دون استخدامها.

بعد البحث عن العديد من سلاسل رسائل GitHub التي جربت طرقًا مختلفة ، وجدت أن الآخرين يواجهون نفس المشكلة حيث انتهى الحل بإلغاء الاشتراك في تجميع تجميع MVC Razor مع:

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

مما سمح بنشر المشروع. خلال فترة تجربة المفاتيح المختلفة لإصلاح البنية المعطلة ، اكتشفنا أيضًا أنه يمكننا تقليل البصمة المنشورة بمقدار 150 .dlls في /refs/*.dll عن طريق إلغاء الاشتراك في البيانات الوصفية التي كانت تضخم بشكل غير ضروري تطبيق الويب .NET Core 2.0 الخاص بنا عن طريق إلغاء الاشتراك في البيانات الوصفية التي تحتاجها Razor مع:

<PreserveCompilationContext>false</PreserveCompilationContext>

لذلك أجبرنا بشكل أساسي على تشغيل whack-a-mole لمعرفة المفاتيح التي نحتاجها لإخبار الأدوات بأننا لا نستخدم MVC لمنعها من كسر تصميمات المشروع ومن إخراج البيانات الوصفية غير الضرورية التي تحتاجها تطبيقات MVC / Razor فقط. كان من الأفضل كثيرًا البدء بحزمة بيانات وصفية "أساسية" حيث لا يمكن أن تكون مثل هذه المشكلات ممكنة نظرًا لأن الأدوات لا يمكن أن تفترض أن كل تطبيق يستخدم MVC لأن وحدات بت MVC لن تكون موجودة.

في حين أنه من السهل القول أن ASP.NET Core لا يزال منصة ترحيب تشجع على التجريب وإنشاء واستخدام "أطر عرض" بديلة ، فإن تجميع أطر عمل الويب الموصوفة مثل MVC هو أكثر الأشياء عدائية التي يمكن القيام بها لتثبيط الإنشاء و استخدام البدائل المذكورة. يعد قضاء بعض الوقت لإلقاء نظرة على عدد البدائل الشائعة الناشئة مقياسًا جيدًا لمعرفة مدى جاذبية المنصة بالنسبة لهم.

إذا كان المقصود أن يتضمن كل تطبيق ASP.NET Core MVC أكثر من أي "إطار عرض" بديل آخر (بما في ذلك ملف .cs واحد من طرق ext) فسوف يبدو أنه "ثقيل الوزن" "ومرهقة من استخدام MVC المجمعة ، حيث يجب دمجها جميعًا معها + أي شيء آخر يحتاجه إطار العرض.

باختصار ، سيكون من الأفضل أن يكون "MVC" مشتركًا ولم يتم تضمينه في حزمة .App ، ولكن إذا كان القرار لا رجوع فيه ، فهل يمكننا على الأقل الحصول على قاعدة بيانات وصفية رسمية للخط الأساسي لا ر تضمينها؟

يُرجى إدراك أن لدينا مئات الآلاف من العملاء ، وأن عددًا قليلاً منهم فقط يأتون إلى GitHub لمشاركة التعليقات.

IMO لا يتم تمثيل الطلب على حزمة البداية غير المتضخمة ، الحكاية: من بين جميع قوالب مشروع C # /. NET التي أنشأناها لـ VS 2012 و VS 2013 و VS 2015 و VS 2017 و .NET Core ، وهو النموذج الأكثر شيوعًا باستمرار لقد كان دائمًا قالب "فارغ" إلى حد بعيد ، والذي كان أيضًا نقدًا متكررًا لـ ASP.NET الكلاسيكي بأن قالب ASP.NET الافتراضي الفارغ الخاص بـ VS.NET لم يكن فارغًا بدرجة كافية. كان هذا هو الوقت الذي يمكنك فيه إنشاء ASP.NET .NET Framework كلاسيكي "فارغ" بدون MVC ، ولكن الآن في إطار عمل ASP.NET Core الأحدث والأخف وزنًا والأكثر نمطية ، تأتي MVC مجمعة ضمن الحد الأدنى من حزمة البدء الموصى بها.

نقوم أيضًا بجمع المعلومات من الزيارات الشخصية والمكالمات الهاتفية ورسائل البريد الإلكتروني ووسائل التواصل الاجتماعي وطلبات دعم العملاء والمدونات

لا يحب الناس الانتفاخ الذي غالبًا ما يعادل تعقيدًا غير قابل للإزالة ، فالمطلوب على الأرجح هو جعل المشاريع بسيطة قدر الإمكان ، وهو ما يجب أن يكون التركيز ويمكن القيام به دون تضخيم المشاريع الافتراضية.

من واقع خبرتي ، أن أكون صريحًا هو أسهل في التفكير من الأطر المتضخمة ذات السلوك السحري. إذا كان الأمر واضحًا ، يمكنك التفاعل معه ، والبحث عنه ، والقراءة عنه ، وإزالته ، واختبار التشغيل دون استخدامه (لمعرفة ما إذا كان هو سبب المشكلات) ويكون مرئيًا عند مقارنة المشاريع ذات التكوينات المختلفة. ولكن مع السلوك السحري لأدوات MVC التي تحطم بنيات مشروع mvc / بدون شفرات أعلاه ، لم يكن لدي أي فكرة عن أي جزء من مشروعي كان يقوم بتشغيله ، ولماذا يتم تشغيله ، أو كيفية تعطيله أو كيفية حله. ما زلت غير واثق من أن مشاريعي التي لا تستخدم MVC لا تتباطأ لأن MVC مجمع أو أنه يولد مخرجات دون المستوى الأمثل لأنه يحتاج إلى استيعاب MVC أو Razor.

القياس عن بعد في Visual Studio ، والمزيد.

سيكون من الصعب مقارنة القياس عن بُعد لشعبية حزمة وصفية أساسية غير موجودة ، إذا كانت قد فعلت IMO لكان لديها أكثر من شعبية كافية لاستحقاق إدراجها. في السابق ، كان برنامج "Microsoft.AspNetCore.All" يهدف إلى الطرف الآخر من الطيف ويتضمن الكون ولكن ليس العكس الأكثر فائدة المتمثل في وجود حد أدنى مفيد من الأساس.

من المنطقي إذا كنت لا تبني تطبيق MVC وخيار اختيار خط أساسي بدونه يمكن الوصول إليه بنفس القدر ، فلماذا لا تختاره على خيار البدء الأكثر انتفاخًا الذي يحتوي على MVC؟

تضمين التغريدة

كان من الجيد جدًا أن يكون لديك وقت تشغيل / lib أساسي للويب يمكن لمؤلفي إطار العمل البناء عليه مثل nodejs بدلاً من تجميع العناصر التي لها رأي.

لكن هذا هو بالضبط كيف يعمل. أنت حر في إنشاء تطبيقك بالطريقة التي تريد استخدامها. إذا كنت لا تريد استخدام MVC ، فلا تقم بإضافة البرامج الوسيطة. نعم ، القوالب مفتوحة ولكن يمكنك تغيير التطبيق الخاص بك للقيام بما تريد ، باستخدام ما تريد.

أعتقد أنك تسيء تفسير إطار العمل المشترك قليلاً هنا. عليك فقط أن تراها كنوع من المكتبات القياسية التي تأتي مع .NET Core. لعمل مرجع Node: تخيل أن الإصدار الحالي من Express تم تجميعه مع Node. أنت لا _ ليس لديك_ لاستخدامه ولكنه موجود بالفعل عندما تريد استخدامه.

أما بالنسبة لـ MVC ، فأعتقد أنك لست على دراية بما يتضمنه MVC بالفعل في ASP.NET Core. إذا كنت لا ترغب في استخدام وحدات التحكم وطرق عرض Razor ، فلا بأس ، ولكن من المحتمل أنك ستستمر في استخدام الكثير من وظائف MVC في تطبيقك على أي حال.

إذا كنت لا ترغب في استخدام وحدات التحكم وطرق عرض Razor ، فلا بأس ، ولكن من المحتمل أنك ستستمر في استخدام الكثير من وظائف MVC في تطبيقك على أي حال.

مثل ماذا؟

إذا كنت لا ترغب في استخدام وحدات التحكم وطرق عرض Razor ، فلا بأس ، ولكن من المحتمل أنك ستستمر في استخدام الكثير من وظائف MVC في تطبيقك على أي حال.

نعم ، من فضلك قل ، يأتي عبر رعاية بعض الشيء ، يشارك معظمنا في أطر عمل بديلة مبنية على البرامج الوسيطة / kestrel الأساسية لذلك لدينا فكرة جيدة عما نستخدمه ، تعد وحدات التحكم وطرق عرض Razor مجموعة فرعية صغيرة من MVC ، نحن إعلم أن. تعمل إطارات F # ، Giraffe / Saturn & Zebra ، بشكل أفضل من MVC مع توجيه أفضل ونموذج معالجة مبسط. في العرض ، Zebra x2 أسرع من MVC على TechEmpower ، وهذا هو السبب في أننا نفضل عدم تشغيله افتراضيًا. إذا كان التجميع / الربط قادرًا على تقليل البصمة لاحقًا ، فهذا شيء على الأقل ولكنه سيكون مثاليًا إذا لم يتم تضمينه افتراضيًا للسماح بميدان لعب أكثر تكافؤًا لأطر أخرى ، واكتسب أقصى قدر من السحب لمنصة asp.net الأساسية.

mythz من منظور تنظيمي ، أنت على حق ، هناك بعض التقسيمات المنطقية هنا. ومع ذلك ، فإن أي تقسيم فرعي يأتي مع تعقيد إضافي بشكل كبير ونفقات هندسية إضافية تستغرق وقتًا بعيدًا عن تحسين ميزات المنتج. عندما نتوقع أن تستفيد أغلبية كبيرة من العملاء من مكونات MVC ، فإن تقسيمها لا يستحق التكلفة. الجوانب السلبية للمطورين الذين لا يستخدمونها لا تذكر ، حيث توجد بضعة ميغا بايت إضافية في دليل التثبيت ولا يوجد تأثير على وقت التشغيل إلا إذا قمت بتحميلها.

يمكنني فقط أن أشير إلى mythz لتوضيح هذه النقطة. كلما ازداد اقتران الأشياء ، ازداد تشابكها. يعني وات !؟ يؤثر MVC في بناء تطبيق Asp حتى لو لم ترجع إليه في أي مكان؟!

@نكز
كما كتب الآخرون بالفعل: إنه ليس كذلك. إنها تجميع الأشياء التي لا علاقة لها بوقت التشغيل الأساسي. هل تعتقد أن إطار العمل السريع قد تم تجميعه مع العقدة بشكل افتراضي ، هل تعتقد أن النظام البيئي كان سيصبح نابضًا بالحياة ومتنوعًا؟

كما أنني لا أفهم على الإطلاق كيفية إزالة MVC و SingalR وما إلى ذلك من التثبيت الأساسي وتقديمها كحزمة NuGet واحدة يمكن تصنيف كل منها على أنها "تعقيد إضافي". يقوم المطورون بتثبيت حزم إضافية في معظم الحالات على أي حال. وإذا كان توفيرها كحزم إضافية سيزيد من أوقات الاستعادة "بشكل كبير" ، فهي سمين للغاية على أي حال.

تضمين التغريدة

لكن أي تقسيم فرعي

التقسيم الفرعي الذي يشير إليه هذا هو فصل MVC لذلك يمكن أن يكون لدى ASP.NET Core Apps حد أدنى مفيد من الأساس دون أي أطر عمل مطورة تحدد ما يجب استخدامها لتطوير تطبيقات ASP.NET الأساسية.

يأتي مع تعقيد إضافي بشكل كبير ونفقات هندسية إضافية تستغرق وقتًا بعيدًا عن تحسين ميزات المنتج.

لتوضيح كيفية قراءة ذلك: يتطلب الأمر الكثير من النفقات الهندسية لإزالة النفقات غير الضرورية من كل تطبيق ASP.NET Core لا يستخدم MVC لأنه إذا كان على MVC أن يعمل مثل أي إطار عمل بديل آخر من شأنه أن يضيف تعقيدًا بشكل كبير "إلى MVC".

إذا كان MVC يتطلب تعقيدًا كبيرًا للعمل ضمن نفس خيارات التوسعة التي يجب أن يعمل بها كل إطار عمل بديل آخر ، فهذا يدل على وجود مشكلة في MVC وأي ميزات مضافة لجعله يعمل بسلاسة أكبر يمكن إضافتها لصالح الجميع. تمامًا مثل تشريح وحدة متجانسة ، سيكون تعقيد الأدوات ووقت التشغيل أصغر حجمًا وأقل تعقيدًا مع نقل التعقيد الإضافي إلى حيث ينتمي إلى MVC وتكامله / أدواته.

بدلاً من ذلك ، انتهى بنا الأمر مع الموقف حيث يتم ترسيخ MVC في الأدوات الافتراضية التي يمكن أن تكسر مشاريع النشر وتضخم مخرجات المشاريع التي لا تستخدمها. نظرًا لأنه لا يعمل مثل أي شيء آخر ، فلا توجد طريقة لإخباره أنك تستخدم MVC أو بأي طريقة لإخباره أنك لا تستخدم MVC ، فمن المفترض دائمًا.

عندما نتوقع أن تستفيد أغلبية كبيرة من العملاء من مكونات MVC

حسنًا ، سيكون هذا متوقعًا ، على حساب كل بديل آخر ، إنه إطار العمل الموصوف المجمّع في الحد الأدنى الافتراضي للتثبيت الموصى به ، مثل Apple التي تمنح الجميع أغنية U2 مجانية سواء أحبوا ذلك أم لا.

مساوئ التطوير التي لا تستخدمها لا تذكر

هل سيستفيد المطورون من نظام بيئي أكثر صحة مع المزيد من التنوع والخيارات والابتكار؟

هل يستفيد المطورون من تعريف الارتباك والتشويش الإضافي لما هو "تطبيق ASP.NET Core"؟ "اعتاد أن يكون مثل node.js لـ .NET ، ولكنه الآن أكثر من إطار عمل بائع واحد معتبر حيث يبدأ كل تطبيق بشكل أساسي بمجموعة من العناصر التي لها رأي والتي تصف كيفية إنشاء تطبيقات الويب ، يمكنك التفكير في الأمر على أنه كل يتم تثبيت التطبيق مسبقًا باستخدام Express وتبعياته بشكل افتراضي - يُتوقع منك استخدامه "

هل يستفيد المطورون من الغلاف الخاص بـ MVC؟ لم يتم تثبيته أو تحديثه مثل أي شيء آخر ويعتمد على الأدوات المخفية والسلوك السحري الذي يجب عليك البحث عنه لمعرفة وجوده وتعطيله. الغلاف الخاص مثل هذا هو ما يضيف التعقيد العرضي ، عند التفكير في مشروعك ، يجب عليك الحفاظ على مجموعة مختلفة من القواعد لكيفية عمل MVC مقابل كيفية عمل كل شيء آخر.

إذا كان صريحًا ، فسيؤدي ذلك إلى تحسين قابلية القراءة ويمكنك معرفة من تكوين المشروع أنه تطبيق MVC ، على سبيل المثال:

• ملف Microsoft.AspNetCore.Mvc

مما يشير إلى أنه تطبيق MVC ولتثبيت جميع التبعيات والتكوين التلقائي لجميع احتياجات MVC للأدوات المخصصة - بشكل مثالي باستخدام نفس النموذج المفتوح القابل للتوسيع الذي يمكن لأي شخص آخر الوصول إليه.

من خلال إبقائه في مشروع "Microsoft.AspNetCore.App" الافتراضي ، فإنك تربطه إلى الأبد بكل تطبيق ASP.NET Core ويجعله غير مواتٍ لأي شيء أفضل. كانت صفحات الويب الخاصة بـ ASP.NET عبارة عن إطار عرض Razor آخر تمت إضافته إلى ASP.NET منذ سنوات تم تثبيته وتم تمكين سلوكه السحري الغازي افتراضيًا. لقد جاء مع Web Matrix IDE الخاص به والذي لم يعد مدعومًا أو متاحًا للتنزيل ، لذا فإن ما تبقى لنا هو حالة يتم فيها تضمين تعقيد تقنية ميتة إلى الأبد في ASP.NET الكلاسيكي ويتسبب في حدوث مشكلات لأطر عمل ويب نشطة أخرى ربط استخدام صفحات Razor .cshtml التي تحتاج دائمًا إلى حمل الأمتعة أدناه لمنع صفحات الويب بشكل صريح من كسر أطر العرض الخاصة بها باستخدام:

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

لإعادة تكرار طلبات الميزات بترتيب التفضيل سيكون:

1. قم بتغيير "Microsoft.AspNetCore.App" ليكون الحد الأدنى من خط الأساس المفيد لجميع تطبيقات ASP.NET الأساسية (على سبيل المثال ، بدون MVC).
2. احتفظ بحزمة وصفية مثل "Microsoft.AspNetCore.Base" بحيث يمكن لأي شخص لا يستخدم MVC أن يستخدمها كخط أساسي مفيد.

إذا لم يتم النظر في أي من هذه العناصر ، فهل يمكننا على الأقل الحصول على علامة على مستوى المشروع مثل mvc:enabled = false يمكن لجميع أدوات MVC التحقق منها لتعطيلها ومنعها من العمل؟

mythz أنت تضع الكلمات في فمي. لا يتعلق التعقيد الإضافي بـ MVC ، بل يتعلق ببناء البنية التحتية والتعبئة والتركيب وما إلى ذلك ، وهو أمر ضروري لإنشاء وشحن طبقة أخرى من المكونات بغض النظر عما تتكون منه هذه الطبقات.

إذا لم يتم النظر في أي من هذه العناصر ، فهل يمكننا على الأقل وضع علامة على مستوى المشروع مثل mvc: ممكّن = خطأ يمكن لجميع أدوات MVC التحقق منها لتعطيلها ومنعها من العمل؟

هل يمكنك أن تكون أكثر تحديدًا بشأن ميزات الأدوات التي ترغب في تعطيلها؟ قد يكون هذا يستحق قضية منفصلة.

تضمين التغريدة

لا يتعلق التعقيد الإضافي بـ MVC ، بل يتعلق ببناء البنية التحتية والتعبئة والتركيب وما إلى ذلك ، وهو أمر ضروري لإنشاء وشحن طبقة أخرى من المكونات بغض النظر عما تتكون منه هذه الطبقات.

أي التعقيد الإضافي لما هو مطلوب من أجل تشغيل MVC.

هل يمكنك أن تكون أكثر تحديدًا بشأن ميزات الأدوات التي ترغب في تعطيلها؟ قد يكون هذا يستحق قضية منفصلة.

كانت المشكلتان اللتان واجهتهما بحاجة إلى تكوين /p:MvcRazorCompileOnPublish=false يدويًا والذي كان يمنع مشروعي (بدون صفحات .cshtml) من النشر. العلم الآخر الذي يجب تعطيله هو:

<PreserveCompilationContext>false</PreserveCompilationContext>

كما هو الحال مع معظم السلوكيات السحرية ، أفترض أن هناك المزيد ولكن لا أعرف عنها إلا عندما أواجهها.

بشكل أساسي علامة لتحديد عدم استخدام MVC ولتعطيل جميع الأدوات أو الامتيازات الممكّنة افتراضيًا والتي تمت إضافتها بسبب MVC.

mythz انطلق وقدم هذه المشكلة.

يمكنك في الواقع إنشاء إطار عمل مشترك مشابه لمكدس الخدمة إذا كانت MVC و SignalR dlls الإضافية تمثل مصدر قلق للمستخدمين.

davidfowl هذا يبدو رائعًا حقًا ، يمكنني رؤية بعض حالات الاستخدام المختلفة لأطر العمل التي يوفرها المجتمع. هل هناك أي توثيق على ذلك؟

كما يمكنك أن تتخيل ، هذا ليس شيئًا نبني دعمًا من الدرجة الأولى له لأن عدد الأشخاص الذين يقومون بذلك قليل. قيل أنه يمكنك النظر في كيفية بناء سلوكنا وتقليد هذا السلوك.

davidfowl ستكون الحزمة الأساسية الدنيا مفيدة لجميع تطبيقات MVC - على سبيل المثال ، هناك الكثير من التطبيقات الخفيفة الأخرى والخدمات الصغيرة التي تريد تجاوز جميع الأطر والكتابة مباشرة إلى الاستجابة نفسها. يجب أن يكون هذا الخيار متاحًا في المربع IMO ، ونحن نفضل عدم البدء من قاعدة غير رسمية تتكون من إصدارات الحزمة التي لا نتحكم فيها. من الناحية المثالية ، سيكون كل شيء مضافًا من الحزمة الأساسية بدلاً من البدء من ظل مختلف يتم الاحتفاظ به خارجيًا. ولكن ربما يكون هذا أحد المجالات حيث يمكن للمجتمع الخارجي أن يجتمع معًا للحفاظ على مجموعة فرعية أساسية "AspNetCore" تكون مفيدة لجميع تطبيقات وأطر عمل MVC.

مع ذلك ، أين يجب أن نتطلع إلى إنشاء إطار عمل مخصص؟ ربما سيكون الأمر سهلاً مثل البدء من نسخة مما تم استخدامه لإنشاء "Microsoft.AspNetCore.App" واستبعاد جميع المكتبات غير الأساسية لإعادتها إلى مجموعة فرعية مفيدة.

mythz لماذا تحتاج حتى إلى إطار عمل ، يمكنك فقط استخدام Kestrel الخادم مباشرة. هذا فقط للقول أنه ربما لا تكون نسختك من الضوء هي فكرة شخص آخر عن الضوء أو النواة. لدينا حاليًا رأي وسيكون من المدهش إذا تمكن المجتمع من التقدم هنا وإنشاء قوالب وإطار عمل مشترك بديل كان في حده الأدنى بدرجة كافية. نحن OSS ، كل ما هو مطلوب لصنع شيء مخصص موجود هناك ونحن متجاوبون للغاية وسنساعدك بكل سرور.

natemcmaster يمكنه المساعدة في التفاصيل حول كيفية إنشاء إطار عمل مشترك مخصص.

davidfowl ، لقد اقترحت إنشاء واحدة مخصصة ، فأنا فقط بعد أن تمكنت من البدء من الحد الأدنى من القاعدة المفيدة بدون أطر عمل ذات رأي. لا نريد الإشارة إلى حزم متعددة بشكل فردي لنفس السبب الذي يوصى به لجميع تطبيقات ASP.NET الأساسية للإشارة إلى "Microsoft.AspNetCore.App" - يمكن الوصول إليها بشكل أكبر لتكون قادرة على الإشارة إلى حزمة واحدة.

هذا فقط للقول أنه ربما لا تكون نسختك من الضوء هي فكرة شخص آخر عن الضوء أو النواة.

يبدو أن الجميع متفقون هنا على أن MVC لا ينتمي إلى الحزمة الأساسية. "المنتج" الآخر الوحيد الذي يبدو أنه تم تضمينه هو SignalR الذي أتخيل أنه سيكون له استخدام أقل من MVC وسبب أقل للتضمين. لست على دراية كاملة بما هو موجود في كل حزمة ولكن يبدو أن كل شيء آخر مفيد بشكل عام وجزء مساعد من "النظام الأساسي" لـ ASP.NET Core.

حسنًا ، دعني أطرح اقتراحًا لمحاولة أن أكون بنّاءً هنا. نحن لا نغير Microsoft.AspNetCore.App ، نعتقد أنه شيء سيحتاجه ويستخدمه غالبية المستخدمين. دعنا نقدم طبقة أخرى هي هذا الإطار المشترك "الأساسي" (لقد فعلنا شيئًا كهذا في الأصل مع https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497). هذا هو إطار العمل المشترك الذي ستؤسس عليه هذه الأطر الأخرى (مثل Nancy و ServiceStack).

سنستمر في شحن قوالبنا الافتراضية مع Microsoft.AspNetCore.App كما هو الحال الآن ولكن مؤلفي إطار العمل مثلك يمكنهم الحصول على قوالب أخرى تستخدم إطار العمل المشترك الأساسي.

ملاحظة: لا يمثل هذا الموضوع عن بُعد أي نوع من غالبية عملائنا ، لذلك لن أستخلص استنتاجات من هنا فقط. نحصل على تعليقات من العديد من الأماكن ، ولدينا إرشادات جيثب الأكثر صخباً وشغفاً.

نعم ، أعتقد أن هذا أقرب إلى احتواء الكثير من الأساسيات لتهيئة تطبيق وتشغيله. من الأقسام في Microsoft.AspNetCore.App ، نستخدم أيضًا:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

لذلك سيكون من الجيد أيضًا تضمين أشياء مثل تجريدات HTTP والاستضافة والتسجيل والتكوين (مفيدة لمعظم تطبيقات HTTP) وأي شيء آخر يراه أي شخص مناسبًا. أفضل ما لدي هو عدم تضمين MVC / SignalR.

والآن أصبح الأمر ممتعًا. كما قال ديفيد بالفعل: الناس مختلفون
أفكار لما تعنيه كلمة "جوهر". من وجهة نظري لا أعتقد أن DependencyInjection
يجب أن يكون في. / shrug

آم دو ، 8. نوفمبر 2018 أم 08:30 Uhr schrieb Demis Bellot <
[email protected]>:

نعم ، أعتقد أن هذا أقرب إلى احتواء الكثير من الضروريات
تكوين تطبيق وتشغيله. من الوديعة في
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App نحن أيضًا
استخدام:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

لذا فإن أشياء مثل تجريد HTTP والاستضافة والتسجيل والتكوين
(مفيد لمعظم تطبيقات HTTP) سيكون من الجيد أيضًا تضمينه وأي شيء
أي شخص آخر يراه مناسبا. أفضل ما لدي هو ألا أمتلك
تم تضمين MVC / SignalR.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

mythz يتم تضمين معظم هؤلاء بشكل مؤقت.

forki 😆 مرحبا بكم في عالمنا.

نحن لا نغير Microsoft.AspNetCore.App ، نعتقد أنه شيء سيحتاجه ويستخدمه غالبية المستخدمين.

اشهر اخر كلمات. هذا هو تبرير كل قرار سيء - "نعتقد أنهم بحاجة إليه".

انت تعرف ماذا اعتقد؟ يجب أن تبدأ Microsoft في التعامل مع قاعدة المطورين الخاصة بها كمهندسين أذكياء مستقلين وليس كمطورين للأغنام ، ونعم يا رفاق لديك العديد من مطوري الأغنام ، الذين سيتابعون ويستخدمون كل ما ترميه عليهم ، لكن المطورين الآخرين الأكثر صوتًا هم الذين سيصنعون حياة نابضة بالحياة المجتمع وبناء شركات ناشئة جديدة على .NET المكدس.

من الجيد أحيانًا الاستماع إلى المستخدمين المتميزين.

بغض النظر ، لن نغير Microsoft.AspNetCore.App. لقد قدمت حلاً وسطاً أعتقد أنه يلبي المتطلبات هنا.

forki إذا كنت تستخدم aspnet core فأنت تواجه DI على أي حال ، فمن الأفضل جعله يتضمن طرق الراحة بشكل افتراضي (احصل على الخدمة، GetRequiredServiceوالإعجابات في تلك الحزمة). ومهلا F # لا يمكنها حتى إنشاء تلك من تلقاء نفسها بسبب T المفقود:> U قيد https://github.com/fsharp/fslang-suggestions/issues/255 لذا ¯_ (ツ) _ / ¯

أود أن يكون هذا الإطار المشترك الأساسي davidfowl مذكورًا ... أعتقد أن mythz و @ dustinmorris سيكونان على ما يرام مع مثل هذا النهج. هذا أيضًا مناسب لـ Saturn @ Krzysztof-Cieslak

أنت تواجه DI على أي حال

أعلم وقد أجرينا تلك المناقشة عدة مرات. إنه فقط لا أفضل ذلك
؛-) لكن هذا ما هو عليه...

أنا الاب ، 9 نوفمبر. 2018 ، 10:57 قبعة Nino Floris [email protected]
geschrieben:

forki https://github.com/forki إذا كنت تستخدم نواة aspnet فأنت
المواجهة مع DI على أي حال ، من الأفضل جعلها تشمل طرق الراحة من خلال
الافتراضي (الحصول على الخدمة ، GetRequiredService وما شابه ذلك في ذلك
صفقة). ومهلا F # لا يمكن حتى إنشاء تلك من تلقاء نفسها بسبب المفقودين
T:> U قيد fsharp / fslang- اقتراحات # 255
https://github.com/fsharp/fslang-suggestions/issues/255 لذا ¯_ (ツ) _ / ¯

أود الحصول على إطار العمل المشترك الأساسيdavidfowl
https://github.com/davidfowl المذكورة ... أعتقدmythz
https://github.com/mythz و dustinmorris
https://github.com/dustinmorris سيكون كلاهما على ما يرام مع مثل هذا النهج.
هذا أيضًا مناسب لـ Saturn @ Krzysztof-Cieslak
https://github.com/Krzysztof-Cieslak

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

تم تحديث المنشور الأصلي ليشمل:

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

يتم سحبها من إطار العمل المشترك وسيتم شحنها كحزم NuGet. تعتمد هذه التجميعات على واجهات برمجة تطبيقات IdentityModel التي لا تتلاءم مع الإرشادات الخاصة بإطار العمل المشترك. لقد بدأنا العمل مع فريق IdentityModel ونفكر في إعادة وضعها في إطار العمل المشترك في المستقبل. cref https://github.com/aspnet/AspNetCore/pull/6035

قم بتحديث المنشور الأصلي ليشمل Microsoft.AspNet.WebApi.Client. راجع https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732.

غالبًا ما أشعر بالارتباك بدرجة كافية لأنه ما أحتاج إلى تضمينه.

Talking Visual Studio - هل من المفترض أن أفتح العقدة Microsoft.AspNetCore.App وأن أرجع كل شيء موجود بالأسفل مع ما قد أكون قد قمت بتثبيته بشكل فردي؟

أقوم ببعض التنظيف المنزلي وأرى أن لدي هذه الحزم. إذن ما هي الزائدة عن الحاجة؟

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

لقد فوجئت تمامًا برؤية أنه تم تضمين أدوات SpaServices و EntityFramework حاليًا (وهو ما لم أدركه من قبل - وهو أمر رائع) - ولكن لدي أيضًا بعض المراجع القديمة 2.2.1 والتي لا يمكن أن تساعد في أي شيء.

النقطة المهمة هي - هل يمكن إجراء بعض أعمال التنسيق الأفضل مع فريق Visual Studio للتأكد من أن IDE أكثر ذكاءً قليلاً من خلال فهم هذه الحزم الضخمة وإخباري أنه من الآمن إزالة شيء ما - ثم في الإصدار 3 يخبرني أنني بحاجة إلى إضافته العودة مرة أخرى ؛-)

simeyla شكرا على ردود الفعل. ما تقوله متعلق بالموضوع ، لكنه ليس بالضبط ما يدور حوله هذا الموضوع. ستكون الأدوات لتحسين مراجع الحزمة ميزة جديدة في Visual Studio. يمكن أن تكون هذه الميزة مفيدة بشكل عام ، ليس فقط لهذا السيناريو ، لذلك أقترح إرسال هذه التعليقات إلى Visual Studio مباشرة. في VS ، استخدم "تعليمات> إرسال ملاحظات ...". إذا قمت بمشاركة الرابط بعد إنشاء المنشور ، فيمكنني إعادة توجيهه داخليًا إلى زملائنا الذين يعملون على VS.

في الإصدار 3.0 ، سنزيل حزمة Microsoft.AspNetCore.App الوصفية تمامًا ونجري الكثير من التعديلات على الحزم التي نشحنها. لقد بدأنا في توثيق كيفية الترقية من 2.x إلى 3.0 وسنواصل تحديث هذا المستند بينما ننتهي من قائمة التجميعات التي يتم شحنها في الإصدار 3.0.

الانتقال إلى معلم "المناقشات" لأن هذا العنصر لا يتتبع أي عمل ، بل سنقوم بتحديثه مع تغير تفاصيل التنفيذ.

تمت إضافة Microsoft.Extensions.DependencyModel إلى القائمة. تم التغيير كجزء من https://github.com/aspnet/AspNetCore/pull/10271

السؤال هناnatemcmasterDamianEdwards، وهناك ذكر للقوالب وجود كل ما هو مطلوب لبناء محليا. مع هذا الفكر وإزالة مكتبات المصادقة ، هل هذا يعني أن أي قالب مصادقة لن يتم إنشاؤه في وضع عدم الاتصال في 3.0؟ أتفهم أنه لن تعمل أي مكتبة مصادقة في وضع عدم الاتصال ، ولكن إذا لم يكن لدي ذاكرة تخزين مؤقت nuget ، فيمكنني نظريًا الحصول على فشل في الإنشاء بعد تجديد قالب مصادقة جديد إذا كنت غير متصل بالإنترنت. يبدو أن هذه تجربة سيئة.

نعم ، هذه إحدى نتائج هذا التغيير. اعتبارًا من المعاينة 6 (قريبًا) ، dotnet new mvc ، dotnet new razor ، dotnet new web وغيرهم ليس لديهم أي PackageReferences ، لذلك لا ينبغي أن يتأثروا ، ولكن تحديد خيارات إضافية ، مثل --auth individual قد يؤدي إلى وجود PackageReference والذي يتطلب تنزيل الحزمة.

نحن نجري مقايضة مقصودة هنا. على الرغم من أن القوالب التي تحتوي على PackageReference لن تستعيد وضع عدم الاتصال على جهاز نظيف ، إلا أننا نتجنب أيضًا العديد من المشكلات التي تأتي من محاولة إنشاء ذاكرة تخزين مؤقت NuGet غير متصلة بالإنترنت معبأة مسبقًا (بالنسبة للمبتدئين ، راجع https://github.com/dotnet/ dotnet-docker / issues / 237 و https://github.com/NuGet/Home/issues/6309 و http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .لغة البرمجة).

أتفهمnatemcmaster تمامًا وأحصل على المنطق ، فقط يحتاج إلى التوثيق جيدًا أو سيكون هناك عدد كبير من المشكلات التي تم فتحها عند الإصدار الأولي 3.0 حيث يقول الناس إن dotnet new webapp --auth Individual لا يتم إنشاؤه.

هل يمكن لأي شخص أن يعلمي لماذا يتم تصنيف Microsoft.AspNetCore.Authentication.JwtBearer بالاعتماد على .netcoreapp3.0؟ ألا يمكن أن يكون على .netstandard2.x؟ أرغب في استخدامه في مكتبة صفية وأحب أن أبقي جميع الكتب الدراسية الخاصة بي. netstandard

buvinghausen https://github.com/aspnet/Announcements/issues/324

Pilchie أعتقد أن هذه المشكلة تستحق الاستدعاء في وثائق ASP.NET Core 3.0. كما ذكرنا أعلاه ، سيحتاج المستخدمون الذين يقومون بالترقية إلى 3.0 إلى إضافة <PackageReference> لتعويض واجهة برمجة التطبيقات التي خرجت من Microsoft.AspNetCore.App.

Bomret تقريبًا كل تطبيق عميل في العالم الحقيقي

نحن بالتأكيد لا نفعل ذلك ، وأعرف عددًا قليلاً من الأشخاص في المتاجر الأخرى الذين يستخدمون .net core للتطبيقات التي لا تحتاج إلى خادم ، وويب واجهات برمجة التطبيقات ، وما إلى ذلك ، حيث لا نحتاج مطلقًا إلى MVC.

الإغلاق ، منذ أن قمنا بشحن 3.0 اليوم.

نحن بحاجة إلى نقل هذه القائمة إلى المستندات

davidfowl تمت إضافته: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30؟view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete- مراجع الحزمة

pranavkm تلك القائمة هي في الواقع عكس ذلك تمامًا: الأشياء التي لم تعد حزم ولكن من المحتمل أنها لا تزال في إطار العمل المشترك.

يتعلق هذا بالأشياء التي تمت إزالتها من إطار العمل المشترك ، ولكن من المحتمل أن تكون متاحة الآن كحزم فقط.

scottaddie هذه هي القائمة التي سنحتاج إلى الرجوع إليها في مستند تأليف مكتبة ASP.NET Core.

DamianEdwards هذا - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30؟view=aspnetcore-3.0&tabs=visual-studio#add -package-المراجع للإزالة -جمعيات؟

هذا هو واحد :)

متأخر على الحفلة ولكن هذا لا يبدو أنه يساعدني في تحقيق هدف تبسيط تطوري.

أ) يبدو الآن أنه إذا كان هناك تحسن في أحد مكونات AspNetCore (على سبيل المثال ، SignalR) ، فنحن بحاجة إلى انتظار إصدار "حزمة دوت نت" جديدة لـ Microsoft.AspNetCore.App لاستخدامه ، مع أخذ كل شيء معه آخر في تلك الحزمة؟
ب) لم يعد بإمكانه إنشاء فئات أدوات مساعدة لـ AspNetCore في مكتبات فئة netstandard (على سبيل المثال ، البرامج الوسيطة Auth). الآن يجب أن تكون مكتبات الصفوف netcoreapp3.0 لإيواء هذه الأشياء. وهذا يعني تقسيم مكتبات فئات المرافق إلى تطبيقات netstandard / netcore.
تحرير: ج) كيف يمكنني تحديد إصدار الحزمة الذي أستخدمه إذا كنت أقوم باستخدام <Project Sdk="Microsoft.NET.Sdk.Web"> ؟ من الواضح أننا نريد أن يكون لدينا بنى قابلة للتكرار على فروع مختلفة بعد تحديث dotnet.

أ) يبدو الآن أنه إذا كان هناك تحسن في أحد مكونات AspNetCore (على سبيل المثال ، SignalR) ، فنحن بحاجة إلى انتظار إصدار "حزمة دوت نت" جديدة لـ Microsoft.AspNetCore.App لاستخدامه ، مع أخذ كل شيء معه آخر في تلك الحزمة؟

يتم شحن SignalR وفقًا للجدول الزمني نفسه مثل باقي AspNetCore ، لذلك لا يوجد تغيير في الجدول هنا.

يتم شحن SignalR وفقًا للجدول الزمني نفسه مثل باقي AspNetCore ، لذلك لا يوجد تغيير في الجدول هنا.

إذن هذا مجرد مثال سيء؟ هل يمكن قول الشيء نفسه عن جميع حزم NuGet الأخرى التي تمت إزالتها؟

يتم شحن SignalR وفقًا للجدول الزمني نفسه مثل باقي AspNetCore ، لذلك لا يوجد تغيير في الجدول هنا.

إذن هذا مجرد مثال سيء؟ هل يمكن قول الشيء نفسه عن جميع حزم NuGet الأخرى التي تمت إزالتها؟

أنا اعتقد ذلك. تستخدم كافة مكونات .NET Core و ASP.NET Core نفس جدول الشحن. إذا لم يكن هناك شيء ما ، فسيتعين عليه الشحن في عبوته الخاصة.

أنا اعتقد ذلك. تستخدم كافة مكونات .NET Core و ASP.NET Core نفس جدول الشحن. إذا لم يكن هناك شيء ما ، فسيتعين عليه الشحن في عبوته الخاصة.

سآخذ كلامك لذلك. ليس لدي أي أمثلة مضادة محددة. لم "تشعر" بهذه الطريقة عند تحديث حزم AspNetCore NuGet في الماضي.