0

Ich habe ein Business-Layer-Objekt, das über Ebenen, Widget reist. Ich möchte, dass ein anderer Satz von Eigenschaften in verschiedenen Layern verfügbar gemacht wird. Hier ist, wie es aussehen würde, wenn Compiler Kommentare lesen:Zugänglichkeit nach Layer nicht nach Assembly

//bl.dll 

public abstract class Widget 
{ 
    //repo only 
    internal virtual Ppty_A {get;set;} //internal to implementation assembly of repo 

    //repo and service only 
    internal virtual Ppty_B {get;set;} //internal to implementation assemblies of repo/svc 

    //everyone inlcuding presentation 
    public virtual Ppty_C {get;set;} 
} 
public interface IWidgetService 
{ ... } } 
public interface IWidgetRepo 
{ ... } 
public class SimpleWidgetService : IWidgetService 
{ ... } 

//dal.dll 
using bl; 
public WidgetRepo 
{ ... } 

//presentation.dll 
using bl; 
public WidgetController 
{ 
    public WidgetController(IWidgetService ...) 
    ... 
} 

Meine Idee ist es, dies zu tun (ich habe das noch nicht getestet und es löst nur die Hälfte des Problems):

//bl.dll 
public abstract class Widget 
{ 
    //repo only simply can't be defined in the abstraction -- can't see you => no contract 

    //repo and service only has to be public? 
    public virtual Ppty_B {get;set;} 

    //at least public is public... 
    public virtual Ppty_C {get;set;} 
} 

//dal.dll 
using bl; 
public SQLWidget : Widget //Or actually DALBLWidget -- see below? 
{ 
    //repo only 
    internal ... 
    internal ... 

    //the rest 
    ... 
} 

Soll ich nur ein anderes abstraktes Widget erstellen (ein DAL-BL Widget und ein BL-UI Widget haben)?

+0

Warum möchten Sie dieses Design? Wäre es nicht eine bessere Idee, benutzerdefinierte DTOs für jede Schicht zu haben und nur die Daten zu übergeben, die benötigt werden? –

+0

Mir ist keine gute Option bekannt, die ganze "Spalte" schmerzlos zu aktualisieren, wenn ich Änderungen vornehmen muss; meine Intuition ist es, die Anzahl der Typen zu minimieren, die die gleiche Entität repräsentieren (ich hatte gehofft, nur eine mehr für das ORM zu benötigen) –

+0

Was meinst du damit, die ganze Spalte zu aktualisieren? –

Antwort

1

Sie können die Widget-Klasse verschiedene Schnittstellen implementieren, die jeder Ebene entsprechen.

public class Widget : IDataLayerWidget, IBusinessLayerWidget 
{ 
// Properties 
} 

public interface IDataLayerWidget 
{ 
    // Properties visible to the DataLayer 
} 

public interface IBusinessLayerWidget 
{ 
    // Properties visible to the BusinessLayer 
} 

In Ihrem Datalayer würden Sie mit dem IDataLayerWidget und in der Business-Schicht arbeiten mit dem IBusinessLayerWidget.

+0

Nicht etwas, was ich dachte, aber was ich will, ist Isolation. Im Moment sehe ich nicht, wie dies verhindern würde, dass die Präsentationsebene mit dem Widget "(IDataLayerWidget)" oder "(IBusinessLayerWidget)" arbeitet. –

+1

Es tut es nicht. Wenn Sie nicht möchten, dass eine Ebene auf die Daten einer anderen Ebene zugreift, geben Sie dieser Ebene keinen Zugriff auf die Daten. Es gibt keine perfekte Lösung für Ihr Problem. Entweder separate Widgets für jede Ebene und die Zuordnung. Das gibt dir Trennung. Oder teilen Sie Ihre Datenobjekte über alle Ebenen und leben Sie mit der hohen Kopplung. –

+0

@SebastianWeber, Ihre "Ja" Antwort ist, was ich leben muss. Ich würde es auch gerne "hier akzeptieren". –

Verwandte Themen