Gastbeitrag: Open Components Framework: Der einfache Weg zur Business Solution, Teil 2

Die LieberLieber Software GmbH liefert mit dem Open Components Framework (OCF) ein Entwicklungswerkzeug zur Generierung von Business Solutions. Die Architektur von OCF ist SOA basiert, also serviceorientiert. Ein vollständiger Datenlayer erleichtert die Umsetzung der gewünschten Businesslogik.

Im ersten Teil „Business Solutions entwickeln mit OCF“ wurde beschrieben, wie einfach man zu einem fertigen Grundgerüst für eine Business Solution kommt und wie man mit Hilfe des Entity Wizard alle benötigten Klassen für einen neuen Businessobjekttyp bekommt.

Die konkrete Implementierung einer beispielhaften Businesslogik ist das Thema dieses Artikels. Mit OCF lässt sich jede Art von Businesslogik umsetzen, jedoch wird die Umsetzung von Anwendungen für den Verwaltungssektor besonders unterstützt. Im letzten Artikel wurde schon kurz beschrieben, welche Entity Typen der Wizard anbietet. Businessobject, BaseDocument und Businesscase sind Typen, die in eGov-Fachanwendungen sehr häufig vorkommen. Businessobject ist das Basisobjekt eines jeden Geschäftsobjektes, enthält u.a. ein Property Identificationstring zur Darstellung der Aktenzahl bzw. Geschäftszahl. BaseDocument und Businesscase (Geschäftsfall) sind Ableitungen.

Im Beispiel werden 2 Entities erzeugt: File (Akt) und Document. File wird auf Basis des Entity Typs „Archive Object“ erzeugt, Document mit „Base Document“. Document erhält zusätzlich noch einen Foreign Key, der auf „File“ verweist.

Damit erhält man alle benötigten Klassen.

Im Design Modus des LinqToSql Mapping Files „Entities.dbml“ fügt man jetzt manuell eine Association zwischen „File“ und „Document“ ein. Damit wird „File“, also der „Akt“, zum Container für Dokumente. Ein typischer Use Case im Verwaltungsbereich.

Als nächstes folgend ein paar notwendige Anpassungen. Der DataContract „File“ muss um ein Property „Documents“ erweitert werden.

[DataContract]public class File : ArchiveObject
{public File()
    {
        Documents = new List<Document>();
    }

    [DataMember]
    public IList<Document> Documents { get; set; }
}

Die Klasse “FileTranslator”, die das Business Entity „File“ in den DataContract „File“ übersetzt, muss ebenfalls angepasst werden, damit etwa beim Abfragen eines Aktes die verlinkten Dokumente gleich mitgeliefert werden.

public class FileTranslator …
{
  protected override void DoTranslate(Model.File from, DataContracts.File to, bool recursive)
  {base.DoTranslate(from, to, recursive);var translator = new DocumentTranslator();
    to.Documents = translator.TranslateCollection(from.Documents);
  }protected override void DoTranslate(DataContracts.File from, Model.File to, bool recursive)
  {base.DoTranslate(from, to, recursive);var translator = new DocumentTranslator();foreach (var document in from.Documents)
  {var item = to.Documents.FirstOrDefault(i => i.ID.Equals(document.ID));if (item == null) to.Documents.Add(translator.Translate(document));
  }
}

Damit sind die Vorbereitungen fertig und man kann die Service Methoden implementieren, beispielhaft die Methoden „CreateFile“, „CreateDocument“ und „GetFileByID“.

Dazu öffnet man das Interface „IBusinessService“ im Contracts-Projekt und ergänzt die Methoden.

[ServiceContract]public interface IBusinessService
{
  [OperationContract]long CreateDocument(Document document);

  [OperationContract]
  long CreateFile(File file);

  [OperationContract]
  File GetFileByID(long objectID);

Die Implementierung des ServiceContracts könnte so aussehen:

public class ServiceImplementation : IBusinessService
{#region IBusinessService Memberspublic long CreateDocument(Document document)
  {var item = new DocumentTranslator().Translate(document);new DocumentRepository().Create(item);return item.ID;
  }public long CreateFile(File file)
  {var item = new FileTranslator().Translate(file);new FileRepository().Create(item);return item.ID;
  }public File GetFileByID(long objectID)
  {var item = new FileRepository().GetObjectByID(objectID);return new FileTranslator().Translate(item);
  }

Damit ist die Implementierung der Businesslogik fertig. Nach dem Update der Service Referenz im Client-Projekt, kann man auf die Service Methoden zugreifen und ein kleines Testprogramm schreiben.

private void CreateFileAndDocument()
{
  var file = new File() { Name = "Akt-Test01" };
  var document = new Document()
  {
    Name = "Doc1",
    IdentificationString = "A01-D01",
    Type = DocumentType.Default,
    DmsID = Guid.NewGuid() // Dummy DmsID};

  var client = new BusinessServiceClient();// Einen neuen Akt erzeugen & speichernvar fileID = client.CreateFile(file);

  document.FileID = fileID; // Referenz auf vorher erzeugten Akt
  // Ein Dokument erzeugen & speichernclient.CreateDocument(document);// Den erzeugten Akt inkl. Dokument(e) ladenvar loadedFile = client.GetFileByID(fileID);// Das 1. Dokument auswählen
  var loadedDocument = loadedFile.Documents.FirstOrDefault();

  client.Close();
}

Damit hat man bereits das Grundgerüst einer „ELAK konformen Fachanwendung“. Eine interessante Erweiterung des Beispiels wäre die Anbindung an den Dms Service Ocf|Dms. Jedes Document Objekt wäre dann mit einem Content verlinkt.

Mehr dazu auf http://www.lieberlieber.com/Ocf und http://blog.lieberlieber.com.

Autor: Dipl.Ing. Franz Helmut Kalchmair, Productmanager Ocf