Korrektre Nutzung von POCOs: Wie POCOs um Business-Logik ergänzen?

Hi zusammen

Habe mal eine grundsätzliche Frage zum Einsatz von POCO-Klassen.

Kurz zur Ausgangslage. Bis anhin hatte ich vier Projekte in meiner Solution:

• MyProject.GUI
• MyProject.Business
• MyProject.Data
• MyProject.Common

Project.GUI referenziert MyProject.Business und dieses wiederum referenziert MyProject.Data. Das Projekt MYProject.Common wird von den drei andren Projekten referenziert.

Im Project.Data verwende ich EF 5.0. Die aus der Datenbank generierten Entitäten habe ich extrahiert und in das Projekt MyProject.Common verschoben. Die POCO-Klassen liegen nun also dort. Zusätzlich verwende ich im Projekt MyProject.Data das Repository-Pattern.

Im Projekt MyProject.Business habe ich die BusinessLogik liegen. Die POCO-Klassen beinhalten keine Logik. Bis jetzt! Meine Frage geht nun dahin, ob es gängige Praxis ist, die POCO-Klassen aus dem Projekt MyProject.Common in das Projekt MyProject.Business zu verschieben und diese Klassen (Sind ja alle Partial) mit Business Logik zu erweitern und diese als Basis für meine BusinessObjekte zu verwenden.

Ein BusinessObjekt würde dann vereinfacht aus zwei Dateien bestehen und wie unterhalb dargestellt aussehen...

 //Meine aus EF generierte POCO-Klasse
public partial class Order 
    {
        public Order()
        {
            this.OrderDetails = new HashSet<OrderDetail>();
        }
    
        public int OrderID { get; set; }
        public string CustomerID { get; set; }
        public Nullable<System.DateTime> OrderDate { get; set; }
		...
            
        public virtual ICollection<OrderDetail> OrderDetails { get; set; }
    }
	
	//Meine selbst erstellte/erweiterte Klasse
	 public partial class Order
    {
        public void AddOrderDetail(int productId, decimal unitPrice, short quantity, float discount)
        {
           //Validierung und weiterer Code
           ...
            //OrderDetail erstellen und hinzufügen
            OrderDetail od = new OrderDetail();
            od.OrderID = this.OrderID;
            od.ProductID = productId;
            
            this.Order_Details.Add(od);
        }
    }

Wird das so gemacht, oder bin ich da total auf dem Holzweg?

Gruss
SuperVisor

Hallo SuperVisor,

das Wichtigste vorne weg...

"partial classes" funktionieren innerhalb der selben Assembly und im selben Namespace.

Wenn also "MyProject.Data" und "MyProject.Business" 2 unterschiedliche "Projekte" sind funktioniert dein Vorhaben so nicht

lg

Grrrrr..... Stimmt, daran hatte ich gar nicht ....

Aber kann/sollen die POCO-Klassen mit der Businesslogik erweitert werden, oder ist es besser, wenn man alle Businessobjekte nochmals neu programmiert? Ich stelle mir das ziemlich aufwendig vor, wenn ich da für viele POCOs separate Businessobjekte mit den fast identischen Eigenschaften erstellen soll...

Gibts dazu irgendwo gute Literatur oder einen Blog?

Gruss

Vorneweg, gute Architektur bedeutet nicht gleichzeitig, das es weniger arbeit ist, sie soll nur die Wart- und Erweiterbarkeit verbessern.

Das Problem in Architektur ist, das es viele Architekten und noch mehr Herangehensweisen gibt.

Diejenigen die verteilt arbeiten müssen fast zwangsläufig Poco's oder DTO benutzen, bei Lokalen Anwendungen werden aber auch ActiveRecord benutzen.

Also ein Richtig gibt es nur bei der konkreten Aufgabe.

Was soll das also bei dir werden?

Hallo SuperVisor,

die Frage wo die BusinessLogik hingehört, wurde ausführlich in 3-Schichten-Design?? [harte vs. weiche (Daten-)Objekte / OOP vs. ActiveRecods] besprochen. Lies das mal durch und falls dir anschließend noch etwas unklar ist, frage möglich konkret nach.

herbivore