Naming of components

Agreed on 1) and 3).

I'd consider 2) as two different components. We use OERA as the name for the backend module. The presentation stuff should be a module/component of it's own because it should be useful on clients that cannot use ABL code on the presentation layer.

Since you copied the term JVM to AVM, why not copy APF from WPF (ABL presentation foundation) for the presentation layer stuff.

Since you copied the term JVM to AVM, why not copy APF from WPF (ABL presentation foundation) for the presentation layer stuff.

We could combine that with the other top layer (the enterprise services) and call it APFEL (and get everyone good and mad with us).

Like your suggestion though: so

2.1 = APF/ES for client-facing stud

2.2 = OERA for backend (Business Components + DataAccess)

2.3 = ??? for common infrastructure? Just "Common Infrastructure"?

-- peter

I agree with Mike on having them separate components, if possible I'll even break the business logic from the data access... this is the place where most OERA frameworks fails to provide the separation, the data access layer in most cases simply means data-server

Following Marian's thought makes me wonder about the division.  It seems to me that there are two more or less orthogonal classifications here.  One is layer based, i.e., presentation, business logic, data access ... although one might add a few depending on philosophy.  The other is source based, i.e., components, framework, and custom code.  A component might be part of a framework, but is a component one uses as is, typically as a part of the shared infrastructure ... the slice at the right of the usual diagram.  Framework is anything one uses to put together code, which can include fragments, templates, small components that don't stand alone, etc.  And custom code is the stuff one writes specific to the application.

So, a grid, no?

BTW, I have recently been talking a lot about subsystems and realized code.  Realized code is a code that one takes as pre-existing from the perspective of the code one is working on ... whether or not one wrote it using the same techniques as the current code.  In particular, the actual implementation of the UI is a good candidate for a subsystem of realized code since it should be entirely separate from any of the other parts of the code and could use any technology.

I should note right up front that OERA is the whole stack - PL, ES, CI, BC DA/DS. I misspoke in my earlier post where I made OERA a backend-only term; I realise that people use it loosely as a term for server-side components (probably because of the lack of client-side bits), but I'd ask that you use OERA for the whole stack, and qualify where necessary.

What I'm hearing is that for should be components named as as such, and that they should be installable as individual components.

• Each of these should be individually installable via the installer. Currently, the application code has a client and server install option, and the whole OERA has a client/server install option, and the support (OE.Core and OE.Lang) have an install option
• Dependencies between pacakges should be kept a minimum. Dependencies can go "down" (direction from app to sdk). Note that all components are dependent on the SDK at a minimum; this is an acceptable dependency to me.
• There should be installer options for client and server, and possibly also multiple components. So "application client" would include AutoEdge.Factory.Client.* + AutoEdge.Factory.Common.* + OpenEdge.CommonInfrastucture.Client.* +  + OpenEdge.CommonInfrastucture.Common.* + OpenEdge.Core.* + OpenEdge.Lang.*. This is doable in the existing InnoSetup installer.

We could combine that with the other top layer (the enterprise services) and call it APFEL (and get everyone good and mad with us).

I wouldn't combine the presentation layer and the enterprise services. Our experience from implementing the SmartComponent Library and it's backend is that it much simpler to consider the presentation layer a standard function set, but for enterprise services we need a bigger diversity resulting in more customized implementations.

Understnanding it as separate components will highlight that.

that looks fine, dependencies down are ok as long as it's done at interface level and not the actual implementation.

having separate components in the installer is one thing, having those as separate projects is totally different... if you go for mix and match then those need to be separate projects with separate source code and releases (can be on the same SCM, can be grouped togheter in an installer though); why downloading 20M and get through the whole install process for only 10k component that interest you?

Thus reinforcing the idea of subsystems.  Subsystems should be very, very loosely coupled and one should be able to treat them as a black box when focusing on any other subsystem.

This is just good modern design.

having separate components in the installer is one thing, having those as separate projects is totally different... if you go for mix and match then those need to be separate projects with separate source code and releases (can be on the same SCM, can be grouped togheter in an installer though); why downloading 20M and get through the whole install process for only 10k component that interest you?

The code is already structured in that way. Each of those components is its own source tree (the app and Common Infrastructure components actually have 3 projects each client, server and common-to-both).

that looks fine, dependencies down are ok as long as it's done at interface level and not the actual implementation.

The dependencies are largely done that way, although in certain cases I believe it makes little to no sense to use interfaces. For example OpenEdge.Core.System.EventArgs or OpenEdge.Lang.String. Or any of the ApplicationError descendants.

-- peter

The dependencies are largely done that way, although in certain cases I believe it makes little to no sense to use interfaces. For example OpenEdge.Core.System.EventArgs or OpenEdge.Lang.String. Or any of the ApplicationError descendants.

I am glad that I am not the only one thinking that you cannot/should not abstract everything. Some things are just too trivial.

Creating an implementation dependency is never trivial.  It may seem so in the original implementation, but go to change that implementation later and it can be a different matter.

Creating an implementation dependency is never trivial.  It may seem so in the original implementation, but go to change that implementation later and it can be a different matter.

Amen.