Web API ในโซลูชัน MVC ในโครงการแยกต่างหาก

ฉันกำลังสร้างโครงการ MVC4 ใหม่และการวิจัยทำให้ฉันเชื่อว่าตอนนี้การสื่อสารจากจาวาสคริปต์ไปยังฝั่งเซิร์ฟเวอร์ทำได้ดีกว่าผ่านเฟรมเวิร์ก Web API มากกว่าการดำเนินการของคอนโทรลเลอร์ ความเข้าใจของฉันถูกต้องในเรื่องนี้หรือไม่?

ฉันคิดว่าฉันสามารถแบ่งปันคุณลักษณะทั้งหมดของฉันและอื่น ๆ ระหว่างเว็บ API และตัวควบคุม MVC ได้ดูเหมือนจะไม่เปลี่ยนแปลงครั้งใหญ่สำหรับฉัน

เมื่อฉันตั้งค่าแอปพลิเคชันฉันต้องการแยกส่วนประกอบออกเป็นโปรเจ็กต์ แผนของฉันคือมีโครงการ MVC และโครงการเว็บ API แต่ฉันได้พบกับปัญหา ตัวอย่างเช่นฉันมี 2 แอพเช่นนี้การตั้งค่าเส้นทางแยกต่างหาก ฯลฯ เป็นต้น

ดังนั้นคำถามของฉันคือในแอปพลิเคชัน MVC เฟรมเวิร์ก API ของเว็บควรอยู่ในโปรเจ็กต์เดียวกันหรือควรแยกเว็บ API ออกเป็นโปรเจ็กต์ของตัวเองและแก้ไขปัญหา

น่าเสียดายที่คุณคิดผิดเกี่ยวกับเรื่องนี้ - ฉันคิดว่าฉันสามารถแบ่งปันคุณลักษณะทั้งหมดของฉัน ฯลฯ ระหว่าง web api และตัวควบคุม mvc ดังนั้นในหน้ามันดูเหมือนจะไม่เปลี่ยนแปลงครั้งใหญ่สำหรับฉัน

หลายแนวคิดที่ใช้โดย Web API และ MVC แม้ว่าจะคล้ายกันในตอนแรก แต่ก็ไม่สามารถใช้ร่วมกันได้ ตัวอย่างเช่นแอตทริบิวต์ Web API คือSystem.Web.Http.Filters.Filterและแอตทริบิวต์ MVC คือSystem.Web.Mvc.Filter- และไม่สามารถใช้แทนกันได้

เช่นเดียวกันกับแนวคิดอื่น ๆ อีกมากมายเช่นการผูกโมเดล (กลไกที่แตกต่างกันโดยสิ้นเชิง) เส้นทาง (Web API ใช้ HTTPRoutes ไม่ใช่ Routes แม้ว่าทั้งคู่จะทำงานบน RouteTable ที่เป็นพื้นฐานเดียวกันก็ตาม) ตัวแก้ไขการอ้างอิง (ไม่สามารถใช้ร่วมกันได้) และอื่น ๆ - แม้ว่าจะคล้ายกันก็ตาม พื้นผิวมีความแตกต่างกันมากในทางปฏิบัติ ยิ่งไปกว่านั้น Web API ไม่มีแนวคิดเกี่ยวกับพื้นที่

ท้ายที่สุดแล้วหากสิ่งที่คุณพยายามทำคือการมีวิธีการแสดงเนื้อหา JSON ที่ "ใหม่และอินเทรนด์" ให้คิดให้ดีก่อนที่จะไปตามเส้นทางนั้น ฉันไม่แนะนำให้ปรับโครงสร้างโค้ดที่มีอยู่ใหม่อย่างแน่นอนเว้นแต่คุณจะต้องการใช้ HTTP และสร้างแอปของคุณด้วยวิธีที่ไม่พึงประสงค์

ทุกอย่างขึ้นอยู่กับสิ่งที่คุณกำลังสร้าง หากคุณกำลังเริ่มโปรเจ็กต์ใหม่และสิ่งที่คุณต้องมีก็คือการให้บริการ JSON เพื่ออำนวยความสะดวกในเว็บแอปของคุณ - หากคุณเต็มใจที่จะใช้งานกับโค้ดที่อาจซ้ำกัน (เช่นสิ่งที่ฉันกล่าวไว้ข้างต้น) Web API สามารถโฮสต์ได้อย่างง่ายดายภายใน โครงการเดียวกับ ASP.NET MVC

ฉันจะแยก Web API ออกเป็นโปรเจ็กต์แยกกันก็ต่อเมื่อคุณกำลังจะสร้าง API ที่เหมาะสมสำหรับบริการออนไลน์ของคุณซึ่งอาจจะถูกใช้โดยลูกค้าภายนอกหรือโดยอุปกรณ์ต่างๆเช่นการเติมน้ำมันแอพมือถือของคุณ

IMO ความปลอดภัยและการปรับใช้ควรขับเคลื่อนการตัดสินใจของคุณ เช่นหากแอป MVC ของคุณใช้การตรวจสอบสิทธิ์แบบฟอร์ม แต่คุณสนใจที่จะใช้การรับรองความถูกต้องขั้นพื้นฐาน (ด้วย SSL) สำหรับ API ของคุณโครงการแยกต่างหากจะทำให้ชีวิตของคุณง่ายขึ้น หากคุณต้องการโฮสต์ไซต์ของคุณที่ www.example.com แต่โฮสต์ API ของคุณเป็น api.example.com (เทียบกับ www.example.com/api) โครงการแยกต่างหากจะทำให้ชีวิตของคุณง่ายขึ้น หากคุณแยกโครงการและโดเมนย่อยออกจากกันและคุณตั้งใจจะใช้ประโยชน์จาก API ของคุณเองจากแอป MVC คุณจะต้องหาวิธีจัดการกับปัญหานโยบายแหล่งกำเนิดเดียวกันสำหรับการเรียกใช้ API ของฝั่งไคลเอ็นต์ วิธีแก้ปัญหาทั่วไปคือการใช้ประโยชน์จากjsonpหรือCORS (โดยเฉพาะอย่างยิ่งถ้าคุณสามารถทำได้)

อัปเดต (26/3/2556): การสนับสนุน CORS อย่างเป็นทางการกำลังจะมา: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

หลังจากประสบการณ์ระดับหนึ่ง (การสร้าง API สำหรับแอพและสำหรับ mvc) ส่วนใหญ่ฉันทำทั้งสองอย่าง

ฉันสร้างโปรเจ็กต์แยกต่างหากสำหรับการโทร api ที่มาจากไคลเอนต์อื่นหรืออุปกรณ์อื่น (แอพ Android / IOS) สาเหตุหนึ่งเป็นเพราะการรับรองความถูกต้องแตกต่างกันโดยเป็นแบบโทเค็น (เพื่อให้เป็นแบบไร้สัญชาติ) ฉันไม่ต้องการผสมสิ่งนี้ในแอปพลิเคชัน MVC ของฉัน

สำหรับ javascript / jquery api ของฉันเรียกใช้แอปพลิเคชัน mvc ของฉันฉันชอบที่จะทำให้สิ่งต่างๆเรียบง่ายดังนั้นฉันจึงรวม web api ไว้ในแอปพลิเคชัน MVC ของฉัน ฉันไม่ได้ตั้งใจที่จะมีการรับรองความถูกต้องโดยใช้โทเค็นด้วยการเรียก javascript api ของฉันเพราะเดี๋ยวก่อนมันอยู่ในแอปพลิเคชันเดียวกัน ฉันสามารถใช้[authorize]แอตทริบิวต์บนปลายทาง API ได้เมื่อผู้ใช้ไม่ได้เข้าสู่ระบบเขาจะไม่ได้รับข้อมูล

นอกจากนี้เมื่อจัดการกับตะกร้าสินค้าและคุณต้องการจัดเก็บตะกร้าสินค้าของผู้ใช้ในเซสชัน (ขณะที่ไม่ได้เข้าสู่ระบบ) คุณจะต้องมีสิ่งนี้ใน API ของคุณเช่นกันหากคุณเพิ่ม / ลบสินค้าผ่านรหัสจาวาสคริปต์ สิ่งนี้จะทำให้ API ของคุณมีสถานะอย่างแน่นอน แต่จะช่วยลดความซับซ้อนใน MVC-API ของคุณด้วย

สตีเวนจาก SimpleInjector (กรอบงาน IoC) ให้คำแนะนำสองโครงการที่แยกจากกัน: DependencyResolver.SetResolver และ HttpConfiguration.DependencyResolver ใน WebAPI แตกต่างกันอย่างไร

เมื่อไม่นานมานี้ฉันได้ทำสิ่งเดียวกันเกือบทั้งหมด: ฉันเริ่มต้นด้วยโครงการแอปพลิเคชันเว็บ MVC 4 ใหม่โดยเลือกเทมเพลต Web API ใน VS2012

สิ่งนี้จะสร้าง Web API ที่โฮสต์ในแอปพลิเคชันเดียวกับ MVC

ฉันต้องการย้าย ApiControllers ไปไว้ในโปรเจ็กต์ไลบรารีคลาสแยกต่างหาก สิ่งนี้ค่อนข้างง่าย แต่วิธีแก้ปัญหานั้นซ่อนอยู่เล็กน้อย

ใน AssemblyInfo.cs ของโครงการ MVC 4 ให้เพิ่มบรรทัดรหัสที่คล้ายกัน

[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]

ตอนนี้คุณต้องการคลาส LibraryRegistrator (อย่าลังเลที่จะตั้งชื่ออะไรก็ได้)

public class LibraryRegistrator
    {
        public static void Register()
        {
            BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
        }
    }

ในโครงการ MVC 4 ยังเพิ่มการอ้างอิงไปยังไลบรารี Api

ตอนนี้คุณสามารถเพิ่มตัวควบคุม Api ลงในไลบรารีคลาสแยกของคุณเอง (yourown.dll)

แม้ว่าโครงการของคุณจะซับซ้อนถึงขนาดต้องรับประกัน "ส่วนหน้า" สองรายการ แต่ฉันก็ยังคงพิจารณาแยก webapi ออกเป็นโครงการแยกต่างหากเป็นทางเลือกสุดท้าย คุณจะปวดหัวในการปรับใช้และคงเป็นเรื่องยากสำหรับมือใหม่ที่จะเข้าใจโครงสร้างของโซลูชันของคุณ ไม่ต้องพูดถึงปัญหาการกำหนดเส้นทาง

ฉันตั้งใจจะให้เนมสเปซ system.web แยกต่างหากใน "เลเยอร์การนำเสนอ" เดียว แม้ว่า webapi จะไม่ได้นำเสนอแต่ก็ยังคงเป็นส่วนหนึ่งของอินเทอร์เฟซของแอปพลิเคชันของคุณ ตราบใดที่คุณยังคงใช้ตรรกะในโดเมนของคุณและไม่ใช่ตัวควบคุมของคุณคุณก็ไม่ควรประสบปัญหามากเกินไป นอกจากนี้อย่าลืมใช้ประโยชน์จากพื้นที่

นอกเหนือจากการตั้งค่า DLL แยกต่างหากสำหรับ Web.Api

เพียงคำแนะนำ:

1. สร้างโครงการ
2. นักเก็ต WebActivatorEx

3. สร้าง aa class Method ที่จะเรียกใช้ app_start

   [แอสเซมบลี: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Start")]

   [แอสเซมบลี: WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "Shutdown")]

4. ลงทะเบียนเส้นทาง web.api ภายใน Start Method

   โมฆะคงที่สาธารณะ Start () {GlobalConfiguration.Configure (WebApiConfig.Register); }

5. อ้างอิงโครงการไปยังโครงการเว็บ เพื่อเปิดใช้งานวิธีการเริ่มต้น

หวังว่านี่จะช่วยได้

ฉันพยายามแยกตัวควบคุม API ออกเป็นโปรเจ็กต์ใหม่ สิ่งที่ฉันทำคือสร้างโปรเจ็กต์ไลบรารีใหม่ย้ายคอนโทรลเลอร์ไปไว้ในโฟลเดอร์ชื่อ API จากนั้นเพิ่มการอ้างอิงของโครงการห้องสมุดในโครงการ MVC

การกำหนดค่า webAPI เหลืออยู่ในโครงการ MVC เอง มันทำงานได้ดี