คำถามติดแท็ก business-logic

ฉันทำงานในบางโครงการที่ใช้ตรรกะทางธุรกิจส่วนใหญ่ในฐานข้อมูล (ส่วนใหญ่ผ่านขั้นตอนการจัดเก็บ) ในอีกด้านหนึ่งฉันได้ยินจากเพื่อนโปรแกรมเมอร์บางคนว่านี่เป็นวิธีปฏิบัติที่ไม่ดี ("ฐานข้อมูลอยู่ที่นั่นเพื่อเก็บข้อมูล วิธีใดบ้างที่ดีกว่า ข้อดีของการใช้ตรรกะทางธุรกิจในฐานข้อมูลที่ฉันนึกได้คือ: การรวมศูนย์ของตรรกะทางธุรกิจ ความเป็นอิสระของประเภทแอปพลิเคชันภาษาการเขียนโปรแกรมระบบปฏิบัติการ ฯลฯ ฐานข้อมูลมีแนวโน้มน้อยที่จะโยกย้ายเทคโนโลยีหรือปรับโครงสร้างครั้งใหญ่ (AFAIK); ไม่มีการทำงานซ้ำในการโยกย้ายเทคโนโลยีแอปพลิเคชัน (เช่น. NET เป็น Java, Perl เป็น Python เป็นต้น) ข้อเสีย: SQL นั้นมีประสิทธิผลน้อยกว่าและซับซ้อนกว่าสำหรับการเขียนโปรแกรมตรรกะทางธุรกิจเนื่องจากการขาดไลบรารี่และภาษาสร้างโครงสร้างของภาษาแอพพลิเคชั่นส่วนใหญ่ โค้ดที่ยากขึ้น (ถ้าเป็นไปได้ทั้งหมด) นำมาใช้ซ้ำผ่านไลบรารี IDE ที่มีประสิทธิผลน้อยลง หมายเหตุ: ฐานข้อมูลที่ฉันกำลังพูดถึงนั้นเป็นฐานข้อมูลเชิงสัมพันธ์ฐานข้อมูลยอดนิยมเช่น SQL Server, Oracle, MySql เป็นต้น ขอบคุณ!

107 database  application-design  business-logic  business-rules 

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

70 mvc  business-logic 

ฉันสร้างแอปพลิเคชัน MVC Java แบบง่ายที่เพิ่มระเบียนผ่านแบบฟอร์มข้อมูลไปยังฐานข้อมูล แอพของฉันรวบรวมข้อมูลมันยังตรวจสอบและเก็บไว้ เพราะนี่คือข้อมูลที่ถูกแหล่งออนไลน์จากผู้ใช้ที่แตกต่างกัน ข้อมูลส่วนใหญ่เป็นตัวเลขในธรรมชาติ ตอนนี้ข้อมูลตัวเลขถูกเก็บไว้ในฐานข้อมูล (เซิร์ฟเวอร์ SQL) ฉันต้องการให้แอปของฉันทำการคำนวณและแสดงผลลัพธ์ ผู้ใช้ไม่สนใจว่าจะทำการคำนวณอย่างไรดังนั้นจึงต้องมีการห่อหุ้ม ผู้ใช้จะต้องสามารถดูข้อมูลที่คำนวณได้ง่ายเท่านั้น (ตัวอย่างเช่นข้อมูลคอลัมน์ลบข้อมูลคอลัมน์ B หารด้วยข้อมูลคอลัมน์ C) ฉันรู้วิธีการเขียนขั้นตอนการจัดเก็บเหมือนกัน แต่ฉันต้องการแอพสามชั้น ฉันต้องการข้อมูลที่ฉันใส่ลงในฐานข้อมูลเป็นบันทึกทำงานโดยดำเนินการคำนวณกับมัน ข้อมูลต้นฉบับควรไม่ได้รับผลกระทบในขณะที่ข้อมูลใหม่การคำนวณภายหลังจะต้องจัดเก็บเป็นบันทึกเอนทิตีใหม่ในฐานข้อมูล ฉันควรเขียนรหัสสำหรับการคำนวณพื้นหลังนี้ที่ไหน เนื่องจากเป็นกฎและตรรกะทางธุรกิจฉันควรใส่ไว้ในไฟล์ JavaBeans ใหม่หรือไม่

44 web-development  mvc  object-oriented-design  business-logic 

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

41 business-logic  n-tier  layers  stored-procedures  separation-of-concerns 

ฉันเพิ่งเริ่มเรียนรู้การพัฒนา Django / Python / Web ปัญหานี้ทำให้ฉันหนักใจมาระยะหนึ่งแล้ว ฉันกำลังสร้างแอปพลิเคชันที่มีแม่แบบหลายรายการใน Django ฉันมี views.py ซึ่งเป็นเพียงการแสดงผลการตอบสนองต่อเทมเพลตนั้นและฉันมี models.py ที่ฉันได้จัดทำฐานข้อมูลของฉัน ในหนึ่งในเทมเพลตของฉันฉันต้องอัปโหลดภาพ (ซึ่งฉันสามารถทำได้) และฉันต้องเรียกใช้ลอจิกซึ่งขึ้นอยู่กับคุณสมบัติของภาพที่อัปโหลด (ยังไม่เสร็จ) ตรรกะนี้เกี่ยวข้องกับการคำนวณจำนวนมาก หลังจากทำการคำนวณตรรกะควรส่งคืนข้อมูล (พิกัด) ที่ประมวลผลไปยังเทมเพลต ฉันสามารถดำเนินการทั้งหมดนี้ได้สำเร็จในแอปพลิเคชันหลามแบบสแตนด์อโลนสำหรับการเรียกใช้ไฟล์หลามหลังจากที่อื่น อย่างไรก็ตามเนื่องจากตอนนี้ฉันต้องการทำให้เว็บแอปพลิเคชันนี้ฉันเริ่มใช้เฟรมเวิร์ก Django ฉันทำการค้นหาจำนวนมาก แต่ฉันยังคงไม่สามารถระบุได้ว่าฉันควรวางไฟล์ Python นี้ตรงไหนกับตรรกะทั้งหมด ฉันควรจะมีไฟล์ที่ใช้คลาสอื่น(logic.py)และเรียกมันจากview.py? ฉัน googled และพบว่านักพัฒนาจำนวนมากวางตรรกะทางธุรกิจของตนใน models.py ใน Django อย่างไรก็ตามฉันรู้สึกว่ามันไม่ถูกต้องเพราะรูปแบบควรสื่อสารกับส่วนหลังเท่านั้น ความช่วยเหลือใด ๆ ที่จะได้รับการชื่นชมขอบคุณล่วงหน้า

26 python  django  templates  business-logic  view 

ฉันได้ยินคนพูดถึงตรรกะทางธุรกิจมากมายในที่ทำงานและออนไลน์และฉันได้อ่านคำถามหลายข้อเกี่ยวกับเว็บไซต์นี้ แต่คำนี้ยังไม่สมเหตุสมผลสำหรับฉัน ตัวอย่างเช่นต่อไปนี้เป็นคำสั่ง (ถอดความ) ที่ฉันมักจะเห็น: "ตรรกะทางธุรกิจเป็นส่วนหนึ่งของโปรแกรมของคุณที่เข้ารหัสกฎเกณฑ์ทางธุรกิจที่แท้จริง" คำจำกัดความส่วนใหญ่ที่ฉันได้อ่านเป็นคำวงกลมเช่นนี้ "ตรรกะทางธุรกิจคือทุกสิ่งที่ไม่เหมือนใครสำหรับแอปพลิเคชันของคุณโดยเฉพาะ" ฉันไม่เห็นว่าสิ่งนี้แตกต่างจาก "แอปพลิเคชันของคุณโดยเฉพาะคืออะไร แต่เป็นตรรกะทางธุรกิจ" เว้นแต่ว่าเราจะมีการคิดค้นใหม่โดยบังเอิญ ดังนั้นชื่อคำถาม "ควรมี Business Logic Layer เหนือ Data Access Layer ของคุณและต่ำกว่า GUI Layer ของคุณ" ในรหัสที่ฉันเขียนตัวเข้าถึงฐานข้อมูลต้องทราบว่าข้อมูลใดที่พวกเขาควรจะเข้าถึงและรหัส UI ต้องรู้มากมายเกี่ยวกับสิ่งที่กำลังแสดงเพื่อแสดงอย่างถูกต้องและไม่มีอะไรทำระหว่าง ทั้งสองแห่งนั้นไม่ใช่การส่งข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ ดังนั้นสิ่งที่ควรจะเป็น Business Logic Layer? "ตรรกะทางธุรกิจควรแยกออกจากตรรกะการนำเสนอ" คำขอคุณสมบัติส่วนใหญ่ที่เราได้รับคือการเปลี่ยนตรรกะการนำเสนอด้วยเหตุผลทางธุรกิจ หากหนึ่งในกฎเกณฑ์ทางธุรกิจคือการแสดงราคาพันธบัตรรัฐบาลสหรัฐฯในรูปแบบที่ 32 โดยค่าเริ่มต้น (ในขณะเดียวกันก็ให้ UI สำหรับผู้ใช้ในการกำหนดค่านั้น) ตรรกะการนำเสนอต้องมีอย่างน้อยต้องรู้ว่ามีกฎนี้อยู่หรือไม่ นอกจากนี้ดูเหมือนว่าส่วนสำคัญของการออกแบบ UX ช่วยให้ผู้ใช้เข้าใจกฎเกณฑ์ทางธุรกิจซอฟต์แวร์ของเราพยายามนำไปใช้ เป็นไปได้หรือไม่ที่ฉันอยู่ในทีมที่ทำแค่ตรรกะทางธุรกิจและตรรกะอื่น ๆ ที่ไม่ใช่ธุรกิจกำลังทำโดยทีมอื่น ๆ ? …

25 architecture  business-logic  business-rules 

ฉันได้ปรับCQRS 1ของคนยากจนมาระยะหนึ่งแล้วเพราะฉันชอบความยืดหยุ่นในการมีข้อมูลละเอียดในแหล่งข้อมูลเดียวให้ความเป็นไปได้ที่ยอดเยี่ยมสำหรับการวิเคราะห์และเป็นการเพิ่มมูลค่าทางธุรกิจและเมื่อต้องการอีกอันสำหรับอ่านที่มีข้อมูล . แต่น่าเสียดายมากตั้งแต่ต้นฉันได้รับการดิ้นรนกับปัญหาที่ฉันควรวางตรรกะทางธุรกิจในสถาปัตยกรรมประเภทนี้ จากสิ่งที่ฉันเข้าใจคำสั่งหมายถึงการสื่อสารเจตนาและไม่มีความผูกพันกับโดเมนด้วยตัวเอง โดยทั่วไปจะเป็นข้อมูล (เป็นใบ้ - หากคุณต้องการ) ถ่ายโอนวัตถุ นี่คือการทำให้คำสั่งถ่ายโอนระหว่างเทคโนโลยีที่แตกต่างได้อย่างง่ายดาย เช่นเดียวกับเหตุการณ์ที่เป็นการตอบสนองต่อเหตุการณ์ที่เสร็จสมบูรณ์แล้ว ในแอปพลิเคชัน DDD ทั่วไปตรรกะทางธุรกิจจะอยู่ภายในเอนทิตีวัตถุค่ารูตรวมโดยรวมพวกเขามีทั้งข้อมูลและพฤติกรรม แต่คำสั่งไม่ใช่วัตถุโดเมนดังนั้นจึงไม่ควร จำกัด เฉพาะการแสดงข้อมูลโดเมนเพราะนั่นทำให้เครียดมากเกินไป ดังนั้นคำถามที่แท้จริงคือตรรกะตรงไหน? ฉันพบว่าฉันมักจะเผชิญกับการต่อสู้ครั้งนี้บ่อยที่สุดเมื่อพยายามสร้างการรวมที่ค่อนข้างซับซ้อนซึ่งกำหนดกฎบางอย่างเกี่ยวกับการรวมกันของค่านิยม นอกจากนี้เมื่อสร้างแบบจำลองวัตถุโดเมนฉันชอบที่จะทำตามกระบวนทัศน์ที่ล้มเหลวอย่างรวดเร็วรู้ว่าเมื่อวัตถุมาถึงวิธีการที่มันอยู่ในสถานะที่ถูกต้อง สมมติว่าการรวมCarใช้สององค์ประกอบ: Transmission, Engine. วัตถุทั้งสองTransmissionและEngineค่าจะแสดงเป็นประเภทซุปเปอร์และมีตามประเภทย่อยAutomaticและManualการส่งสัญญาณหรือPetrolและElectricเครื่องยนต์ตามลำดับ ในโดเมนนี้การใช้ชีวิตที่สร้างขึ้นอย่างประสบความสำเร็จTransmissionไม่ว่าจะเป็นAutomaticหรือManualหรือประเภทใดประเภทหนึ่งEngineก็ใช้ได้ดี แต่การCarรวมรวมจะมีกฎใหม่สองสามข้อใช้งานได้เฉพาะเมื่อTransmissionและEngineวัตถุถูกใช้ในบริบทเดียวกัน กล่าวคือ: เมื่อรถใช้เครื่องยนต์ชนิดส่งได้รับอนุญาตเพียงอย่างเดียวคือElectricAutomatic เมื่อรถใช้เครื่องยนต์มันอาจจะมีประเภทของการอย่างใดอย่างหนึ่งPetrolTransmission ฉันสามารถตรวจจับการละเมิดการรวมกันของส่วนประกอบนี้ในระดับของการสร้างคำสั่ง แต่ตามที่ฉันได้ระบุไว้ก่อนหน้านี้จากสิ่งที่ฉันเข้าใจว่าไม่ควรทำเพราะคำสั่งนั้นจะมีตรรกะทางธุรกิจซึ่งควร จำกัด ชั้นโดเมน หนึ่งในตัวเลือกคือการย้ายการตรวจสอบความถูกต้องทางตรรกะทางธุรกิจไปยังตัวตรวจสอบคำสั่งด้วยตนเอง แต่ดูเหมือนจะไม่ถูกต้องเช่นกัน มันรู้สึกเหมือนว่าฉันจะแยกแยะคำสั่งตรวจสอบคุณสมบัติที่เรียกคืนโดยใช้ getters และเปรียบเทียบมันภายใน validator และตรวจสอบผลลัพธ์ เสียงกรีดร้องดังกล่าวเป็นการละเมิดกฎหมายของ Demeterสำหรับฉัน ยกเลิกตัวเลือกการตรวจสอบความถูกต้องที่กล่าวถึงเพราะดูเหมือนว่าจะไม่สามารถใช้งานได้ดูเหมือนว่ามีใครควรใช้คำสั่งและสร้างการรวมจากมัน แต่ตรรกะนี้ควรอยู่ที่ไหน ควรอยู่ในตัวจัดการคำสั่งที่รับผิดชอบการจัดการคำสั่งที่เป็นรูปธรรมหรือไม่? หรือควรอยู่ในเครื่องมือตรวจสอบคำสั่ง (ฉันไม่ชอบวิธีการนี้เช่นกัน) ขณะนี้ฉันกำลังใช้คำสั่งและสร้างการรวมจากคำสั่งภายในตัวจัดการคำสั่งที่รับผิดชอบ แต่เมื่อฉันทำสิ่งนี้ฉันควรจะมีเครื่องมือตรวจสอบคำสั่งมันจะไม่มีอะไรเลยเพราะCreateCarคำสั่งควรมีอยู่แล้วมันจะมีส่วนประกอบที่ฉันรู้ว่าถูกต้องในกรณีที่แยกต่างหาก …

22 domain-driven-design  business-logic  cqrs 

นี่เป็นคำถามที่ฉันถามกลับไปซักพักแล้ว แต่มันอาจจะดีกว่าที่นี่ ... ที่ที่ฉันทำงานเราได้ย้อนกลับไปในเรื่องนี้หลายครั้งและกำลังมองหาการตรวจสุขภาพ นี่คือคำถาม: หาก Business Objects เป็น data container (เหมือนDTO ) หรือควรมีตรรกะที่สามารถใช้งานบางอย่างกับวัตถุนั้นได้ ตัวอย่าง - นำวัตถุลูกค้าอาจมีคุณสมบัติทั่วไปบางอย่าง (ชื่อรหัส ฯลฯ ) หากวัตถุลูกค้านั้นควรมีฟังก์ชั่น (บันทึก, คำนวณ, ฯลฯ )? การใช้เหตุผลหนึ่งบรรทัดบอกว่าแยกวัตถุออกจากฟังก์ชั่น (ผู้รับผิดชอบหลักเดียว) และวางฟังก์ชันการทำงานในเลเยอร์หรือตรรกะทางธุรกิจ อีกเหตุผลหนึ่งบอกว่าไม่ใช่ถ้าฉันมีวัตถุลูกค้าฉันแค่ต้องการโทรหาลูกค้าบันทึกและทำได้ด้วย ทำไมฉันต้องรู้เกี่ยวกับคลาสอื่นเพื่อบันทึกลูกค้าถ้าฉันใช้วัตถุ? โครงการสองโครงการสุดท้ายของเรามีวัตถุที่แยกออกจากฟังก์ชันการทำงาน แต่การอภิปรายได้รับการยกขึ้นอีกครั้งในโครงการใหม่ ซึ่งทำให้รู้สึกมากขึ้นและทำไม?

19 business-logic  business-rules 

ถ้าฉันมีตรรกะทางธุรกิจทั้งหมดของฉันในรหัสและใช้ประโยชน์จาก Entity Framework ในสถานการณ์ใด (ถ้ามี) ฉันจะย้ายตรรกะทางธุรกิจบางอย่างไปยังขั้นตอนการจัดเก็บดีกว่าแทนที่จะเก็บไว้ในรหัสทั้งหมดหรือไม่ เพื่อความชัดเจนฉันหมายถึงร่วมกับการตั้งค่าปัจจุบัน (ตรรกะทางธุรกิจในรหัส) ไม่ใช่แทนที่จะเป็น ฉันได้เห็นคำถามคล้าย ๆ กันหลายข้อที่ถามถึงข้อดีและข้อเสียของการมีตรรกะทางธุรกิจทั้งหมดในขั้นตอนการจัดเก็บ แต่ฉันไม่พบอะไรมากเกี่ยวกับการใช้ขั้นตอนการจัดเก็บเท่าที่จำเป็นสำหรับตรรกะกรณีขอบ ในรหัส ถ้ามันสร้างความแตกต่างฉันกำลังใช้ MSSQL และ Entity Framework นี่คือสถานการณ์ที่ฉันใช้โพรซีเดอร์ที่เก็บไว้ก่อนหน้านี้: รายงานที่ซับซ้อนซึ่งใช้เวลาไม่กี่นาทีในการเรียกใช้ (นี่คือหน้าเว็บในแอปพลิเคชัน) ฉันพบว่าฉันสามารถเขียน SQL ที่มีประสิทธิภาพมากขึ้น (ใช้เวลาเพียงไม่กี่วินาทีในการเรียกใช้) กว่าที่ LINQ จัดหาให้ เว็บแอปพลิเคชันจำเป็นต้องอ่านและเขียนลงในตารางไม่กี่ตารางในฐานข้อมูลแยกต่างหากซึ่งมีข้อมูลที่ละเอียดอ่อนจำนวนมากซึ่งไม่เกี่ยวข้องกับแอปพลิเคชัน แทนที่จะให้สิทธิ์เข้าถึงทุกสิ่งฉันใช้กระบวนงานที่เก็บไว้ซึ่งทำสิ่งที่ต้องการเท่านั้นและส่งคืนข้อมูลที่ จำกัด เท่านั้น เว็บแอปพลิเคชันสามารถเข้าถึงขั้นตอนการจัดเก็บนี้เท่านั้นโดยไม่ต้องเข้าถึงตารางใด ๆ เป็นต้น โพสต์อื่นที่ฉันได้ดูก่อนถามคำถามนี้: ขั้นตอนการจัดเก็บวิธีปฏิบัติที่ไม่ดีที่หนึ่งใน บริษัท ที่ปรึกษาด้านไอทีรายใหญ่ที่สุดในโลก? ข้อดีข้อเสียของการถือตรรกะทางธุรกิจทั้งหมดในขั้นตอนการจัดเก็บในเว็บแอปพลิเคชัน /programming/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code /dba/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452 เมื่อใดที่จะไม่ใช้ ORM และชอบวิธีการจัดเก็บ?

19 design  sql-server  orm  business-logic  stored-procedures 

ฉันมีเพื่อนร่วมงานที่ปฏิเสธที่จะยอมรับความจริงที่ว่าเครื่องจักรทัวริง (และเครื่องจักรของ Von Neuman ตามส่วนขยาย) ไม่สามารถแก้ปัญหาการหยุดชะงักของตนเองได้: คุณสามารถทำอะไรกับเวลาและเงินเพียงพอ นอกจากนี้เขายังไม่ชอบปัญหาเชิงทฤษฎีที่โต้แย้งว่า: ในสาขาของเราเราจะไม่พบคำถามเหล่านั้น เราเป็นนักพัฒนาแอปพลิเคชั่นไม่ใช่นักวิทยาศาสตร์ตามทฤษฎี มีตัวอย่างที่ดีของปัญหาทางธุรกิจที่ไม่สามารถคำนวณได้ที่ฉันสามารถใช้เพื่อช่วยโน้มน้าวเขาได้หรือไม่?

17 computer-science  theory  business-logic 

วันนี้ฉันได้มีการถกเถียงกันอย่างดุเดือดกับนักพัฒนาคนอื่นในองค์กรของฉันเกี่ยวกับสถานที่และวิธีการเพิ่มวิธีในคลาสที่แมปฐานข้อมูล เราใช้sqlalchemyและส่วนสำคัญของฐานรหัสที่มีอยู่ในโมเดลฐานข้อมูลของเรานั้นเป็นเพียงเล็กน้อยของคุณสมบัติที่แมปด้วยชื่อคลาสการแปลเชิงกลจากตารางฐานข้อมูลไปยังวัตถุหลาม ในการโต้แย้งตำแหน่งของฉันคือว่าค่าหลักของการใช้ ORM คือคุณสามารถแนบพฤติกรรมและอัลกอริทึมในระดับต่ำกับคลาสที่แมป โมเดลเป็นคลาสแรกและถาวรเป็นอันดับที่สอง (อาจคงอยู่โดยใช้ xml ในระบบไฟล์คุณไม่จำเป็นต้องสนใจ) มุมมองของเขาคือพฤติกรรมใด ๆ ที่เป็น "ตรรกะทางธุรกิจ" และจำเป็นต้องเป็นของทุกที่ แต่ในรูปแบบถาวรซึ่งจะใช้สำหรับการคงอยู่ของฐานข้อมูลเท่านั้น ฉันคิดว่าแน่นอนว่ามีความแตกต่างระหว่างตรรกะทางธุรกิจคืออะไรและควรแยกออกจากกันเนื่องจากมีการแยกจากระดับล่างของวิธีการใช้งานและตรรกะโดเมนซึ่งฉันเชื่อว่าเป็นนามธรรมที่จัดทำโดยคลาสโมเดล เป็นที่ถกเถียงกันในย่อหน้าก่อนหน้า แต่ฉันมีเวลายากที่จะวางนิ้วลงบนสิ่งที่เป็น ฉันมีความรู้สึกที่ดีขึ้นเกี่ยวกับสิ่งที่อาจเป็น API (ซึ่งในกรณีของเราคือ HTTP "ReSTful") ผู้ใช้จะเรียกใช้ API กับสิ่งที่พวกเขาต้องการทำแตกต่างจากสิ่งที่พวกเขาได้รับอนุญาตให้ทำ เสร็จแล้ว tl; dr: ประเภทใดที่สามารถหรือควรไปในวิธีการในคลาสที่แมปเมื่อใช้ ORM และสิ่งที่ควรจะออกไปอยู่ในอีกชั้นหนึ่งของสิ่งที่เป็นนามธรรม?

16 orm  abstraction  business-logic 

ฉันรู้ว่ามันแพง แต่ (IMO) ฉันเชื่อว่านี่เป็นวิธีปฏิบัติที่ดีมาก ฉันกำลังพูดถึงกฎอย่างเช่นพูดว่าคุณไม่สามารถบันทึกใบแจ้งหนี้ได้หากคุณไม่ใช่พนักงานขาย ... ดังนั้นในกรณีนี้ให้ยกเว้นว่า "คุณไม่ได้รับอนุญาต" หรือเช่น ... อีกวิธีหนึ่งที่จะมีวัตถุที่มีสถานะหรืออะไรทำนองนั้น มีวิธีอื่นอีกไหม? คุณรู้สึกอย่างไรเกี่ยวกับเรื่องนี้?

16 idioms  business-logic  business-rules  rules-and-constraints 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว คุณเคยมีประสบการณ์เกี่ยวกับบุคคลที่ไม่ได้ทำงานกับโปรแกรมเมอร์ในระหว่างกระบวนการเข้ารหัสหรือไม่? มันเหมือนกับการเขียนโปรแกรมคู่ แต่บุคคลหนึ่งเป็นบุคคลที่ไม่ใช่ด้านไอทีที่รู้เรื่องธุรกิจเป็นอย่างมากอาจเป็นวิศวกรกระบวนการที่มีพื้นฐานทางคณิตศาสตร์ที่รู้วิธีคำนวณสิ่งต่าง ๆ และสามารถเข้าใจโค้ดที่ไม่ใช้สำนวนได้ ฉันพบว่าบางภาษาเฉพาะโดเมนเช่น PL / SQL นั้นค่อนข้างเข้าใจได้ง่ายโดยวิศวกรที่ไม่ใช่ไอที บุคคลเหล่านี้เป็นผู้เขียนรหัสและรับประกันความถูกต้องของสูตรปัจจัย ฯลฯ ฉันพบว่าการเขียนโปรแกรมคู่ชนิดนี้มีประสิทธิภาพมากผู้ใช้ประเภทวิศวกรรมรู้สึกว่าพวกเขายังเป็น "เจ้าของ" และ "ผู้เขียน" ของรหัสและช่วยลดความเข้าใจผิดในกระบวนการสื่อสาร พวกเขายังช่วยออกแบบกรณีทดสอบ การปฏิบัตินี้เป็นเรื่องปกติหรือไม่ มันมีชื่อหรือไม่? คุณเคยมีประสบการณ์คล้าย ๆ กันบ้างไหม?

14 teamwork  requirements  client-relations  business-logic  pair-programming 

ฉันเป็นแฟนตัวยงของการตรวจสอบประเภทคงที่ มันป้องกันคุณจากการทำผิดพลาดแบบนี้: // java code Adult a = new Adult(); a.setAge("Roger"); //static type checker would complain a.setName(42); //and here too แต่มันไม่ได้ป้องกันคุณจากการทำผิดพลาดแบบนี้: Adult a = new Adult(); // obviously you've mixed up these fields, but type checker won't complain a.setAge(150); // nobody's ever lived this old a.setWeight(42); // a 42lb adult …

13 business-logic  static-typing  type-safety 

ดังนั้นฉันจึงสร้าง data access layer ผ่านทาง TDD และได้เข้าหาข้อกังวลเล็กน้อย ฉันไม่ควรเริ่มต้นเส้นทางที่ผิดดังนั้นฉันคิดว่าฉันขอให้พวกคุณดูว่าความคิดของฉันสอดคล้องกับสถาปัตยกรรมที่สะอาดหรือไม่ วิธีการภายใน Data Access Layer ของฉัน (สั้นสำหรับ DAL) จะค่อนข้างง่าย พวกเขาเป็นไปตามขั้นตอนการจัดเก็บในฐานข้อมูล (ไม่มีวิธีอื่นในการโทรเข้าเพื่อรักษาความสะอาด) และพวกเขามีพารามิเตอร์เดียวกันกับที่ทำ พวกเขาเพียงแค่เชื่อมต่อกับฐานข้อมูลและส่งคืนผลลัพธ์แบบสอบถาม นี่คือตัวอย่างหนึ่ง: public int DeleteRecord(int recordId) { recordId.RequireThat("recordId").NotZeroOrLess(); List<SqlParameter> parameters = new List<SqlParameter>(); parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId}); return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray()); …

12 c#  .net  architecture  database  business-logic