CODEWITHSUNDEEP
phparchitectureframeworks
openfrog
openfrog

Reputation: 40735

How should I call a layer of auto-generated code?

I have a framework which works this way: After defining some meta data, it generates PHP code with PHP classes. These classes are abstract and are intended to be subclassed.

For example, if I define a User class in the backend, it will generate an UserBase class which I simply subclass like:

class User extends UserBase {
    //....
}

UserBase supplies some general functionality like the defined properties age, name, email, and getters and setters for these. It does also validation.

Next to that, it generates a UserDataMapper class which can save a User to the DB, or restore a Users from the DB, find Users, delete Users, etc.

The PHP code is split up in 3 parts:

1) System Code ("don't touch it!")

2) Auto-generated Code ("don't change it manually!")

3) User Code ("do what you want here!")

When thinking in layers, System Code doesn't know much about Auto-generated Code (at least for some rare special cases), and doesn't know about User Code. Auto-generated Code uses System Code, but doesn't know anything about User Code. User Code uses both System Code and Auto-generated Code.

I'm writing the documentation for my framework right now and I have trouble with naming the layers here, but especially the layer for the Auto-generated code ;)

So how may I call that? "Service Layer" maybe? Because actually, the auto-generated code is just convenience for the user to help him make his hard life easier, and to help refactoring quickly by just pressing some buttons in the backend.

Would be happy about any suggestions for that. Thanks everyone.

Upvotes: 1

Views: 167

Answers (3)

Ken Fox
Ken Fox

Reputation: 1679

InterViews was a really nice user interface system built in the late 80s. It had a user interface builder called ibuild that was the first time I ever saw a system generate code designed to be customized by sub-classing. http://portal.acm.org/citation.cfm?id=120804

The names of the layers they used were:

  1. InterViews Toolkit
  2. Unidraw System
  3. Core Class (generated code)
  4. Core Sub-Class (custom application code)

The core classes were generated and never modified. For every core class, there was a core sub-class that was just a trivial C++ stub. If a core sub-class didn't exist at code generation time, it was generated, otherwise it was assumed that someone had already customized it. Because the core sub-classes were so trivial, they never changed no matter how the generated code or system code changed.

I wouldn't worry too much about the names of your layers. It's a beautiful model of how to generate code and people will quickly appreciate how it works.

Upvotes: 1

John Parker
John Parker

Reputation: 54445

Hmm... it's a tricky one, as this architecure doesn't really conform to any of the standard models.

That said, 'service layer' seems reasonably appropriate as long as you don't have other system services (such as a mail transmission, logging, etc.) If you do have these services (which I suspect is quite likely), then things will get confusing.

As a suggestion how about the 'abstraction' or 'switching' layer? (It really depends on what facilities this layer provides.)

Upvotes: 1

Ivan Krechetov
Ivan Krechetov

Reputation: 19220

Application Skeleton layer, or just Skeleton?

Upvotes: 1

Related Questions