Book a Demo

Author Topic: Possible EA wrapper library and best practices  (Read 3344 times)

Pedro

  • EA Novice
  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Possible EA wrapper library and best practices
« on: December 18, 2013, 06:04:52 am »
Hello guys,

The add-in project (C#) I'm working on is getting bigger, and it claims for some refactoring. One of the mean issues appointed by the developers is the amount of methods to handle EA functions with regards to their Objects.

I explain: right now, in our code, there are a lot of methods in the CreateX(Y _y, string name, string stereotype). For example:

Code: [Select]
CreateDiagram(Package p, bla, bla);
CreatePackage(Package p, bla, bla);
CreateElement(Package p, bla, bla);
CreateElement(Element e, bla, bla);

I call your attention for the numerous combinations possible, which turns to be impractical to handle... All those methods are static and have more or less the same shape:

Code: [Select]
CreatePackage(Package p, bla, bla){
var p = (Package)null;
           try
            {
                p = inThis.Packages.GetByName(createThis);
            }
            catch
            {
                // inThis does not contain createThis
            }

            if (p == null)
            {
                p = inThis.Packages.AddNew(createThis, withThisType);
            }

            p.Update();
            inThis.Packages.Refresh();
            inThis.Update();
}

When we decided to do something about, we got stopped just in the begging. Some ideas were to Build a static class (say "EAHelper" with public, static methods (say Create *). But this approach simply does not work from the begging. We thought about using generics, something like:

Code: [Select]
public static void Create<T> (T obj, string name, string type){ }
But this won't work because a object T won't have a "Packages" or "Elements" list.

In summary, I'm asking for assistance in order to code a proper class to handle this EA packages, elements, objects, etc from the inside the c# code nicely. If something like this already exist, great! Please, advise. If not, I will do my best to make it as generic and public as possible, since it is very hard to find good programming material for EA.

Thanks in advance,

Pedro Dusso

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Possible EA wrapper library and best practices
« Reply #1 on: December 18, 2013, 05:37:04 pm »
Pedro,

I feel your pain, been there and done that.
That is why I created the Enteprise Architect Add-in Framework

This is an open source C# library that contains all of those methods and wraps the EA objects into UML typed objects.

I use this library as the framework for my EA Navigator add-in. (and other add-ins)

The architecture of the framework is setup in two layers:
- EA Wrappers: wrapper classes around the EA objects to simplify access and to hide the ugly details of the EA API. Repository: Enterprise-Architect-Add-in-Framework
- UML Interfaces: A literal implementation of the UML meta model. All EA Wrappers implement one or more UML interfaces. Repository: https://github.com/GeertBellekens/UML-Tooling-Framework
 UML-Tooling-Framework

You can find the current users of the framework in the repository Enterprise-Architect-Toolpack

A user of the framework (such as the EA Navigator) should only ever access the UML interfaces, and never use the EA Wrappers directly.

The idea behind this double insulation is to shield you from any EA specific ugliness. Switching from one UML tool to another should be as easy as implementing the UML interfaces new set of <UML Tool> Wrappers.

Geert

PS. The framework is not complete (and it will probably never be). I only ever add features I need myself.