Re: [IBMiOSS] Node code organization -- OPENSOURCE

Like many things in software dev, things are not clear-cut.

Obligatory text:

Seperate responsibilities into modules.
The main (highest level) responsibilities in our world are model (the
businesslogic), view (UI), and database (store).
Which modules are created and how these interact (besides giving it an
acronym) depends on the application, and "what works".

The main important concepts which never change is encapsulation
(information hiding), cohesion (more is better) and coupling (less is
better).

On Mon, Jan 15, 2018 at 7:08 PM, Mark Murphy <jmarkmurphy@xxxxxxxxx> wrote:

It seems to me that the differentiation between MVC, MVP, and MVVM only
exists in academia, and in reality MVC frameworks are usually one or more
of these. Take your typical PHP MVC framework. In strict MVC (if there is
such a thing, it seems to be defined differently depending on where you
look, and who is doing the defining) the view can interact with the model,
the controller contains business logic, and the model just contains the
data model. But many proponents of MVC call for a thin controller where
business logic and the data model reside in the model, and the view only
interacts directly with the controller. This is still called MVC, but
sounds a lot more like MVP with a passive presenter to me. And which flavor
you are using really depends on how you code it, and your shop standards.

On Fri, Jan 12, 2018 at 3:35 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

I'll add that other things have transpired ~after~ MVC though before
Node.js; specifically MVVM-type approaches. I am only bringing this up
because there have been post-MVC approaches that have attempted to

address

changing concerns/needs.

Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces

On Fri, Jan 12, 2018 at 12:34 PM, Kevin <kevin@xxxxxxxxxxxxxx> wrote:

Bear in mind that this whole thread is about node.js - not every

possible

web framework out there. It’s amusing that a proponent of MVC would

likely

be a greybeard :)

I think that many shops are still striving to get to a MVC model and

see

it is the holy grail, but the point is that node.js is a relatively new
technology (for some at least) and that learning it or migrating to it

does

not mean you have to implement a MVC pattern. There are other things to
consider that may be better (for your environment).

On 12 Jan 2018, at 13:43, Jim Oberholtzer <

midrangel@xxxxxxxxxxxxxxxxx

wrote:

Well said Pete. Sometimes change for changes sake, and because it

was

done that way before you therefore it's not right anymore is a problem.

The goal is easy, understandable, maintainable code by the developer

that comes after you. MVC is easy, straight forward, and maintainable.
Passé, maybe but who cares. Sometimes we greybeards aren't just old,
rather we are experienced.

--
Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf

Of

Pete Helgren

Sent: Friday, January 12, 2018 7:31 AM
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Subject: Re: [IBMiOSS] Node code organization

So, everyone will have a opinion on this...take mine with a grain of

salt....

The MVC pattern was driven by the need to move from a monolithic

program

to a structure that was more modular, maintainable and organized. So,

even

a monolithic pre-MVC pattern program would have subroutines that broke

out

the different programmatic components. So, building reusable modules

of

Models, Views and Controllers, even if they weren't completely reused

as

a

components, was just a logical extension of a need for organization

wrapped

around the available technology.

The latest craze of "micro-services" is just an extreme extension of

MVC

into today's heterogeneous technology environment. The pendulum will

swing

back into more complete "packages" rather than micro-services at some
point. There is just a practical balance of functional separation and
maintainability that will rule the day.

The term MVC may be passe, but the concept is alive and well and now

living in a micro-service world....

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
Twitter - Sys_i_Geek IBM_i_Geek

On 1/12/2018 2:09 AM, Kevin wrote:
Do you really want a traditional MVC pattern? That’s generally

considered a bit passé. If you are developing something new then I

would

go

with the component approach (ala React, Angular 2 and beyond, Vue etc).

On 12 Jan 2018, at 00:44, Justin Taylor <JUSTIN@xxxxxxxxxxxxx>

wrote:

I ran this command:

$ express hello_world

It generated these directories:

-bin

-public

---images

---javascripts

---stylesheets

-routes

-views

With MVC, I think V=views and C=routes, and I'd need to create a

dir

for M. Does that sound about right?

________________________________
From: Pete Helgren <pete@xxxxxxxxxx>
Sent: Thursday, January 11, 2018 1:42 PM
To: IBMi Open Source Roundtable
Subject: Re: [IBMiOSS] Node code organization

Some frameworks are opinionated and some aren't so it depends if

you

are going to end up fighting conventions or not. I think just

about

any framework with an MVC design pattern will group like

code/objects

together and I even do that for my RPG stuff (which has no

opinion).

Node itself I don't think cares about structure. It is what ever

is

familiar to you, but in most cases my guess is that you'll follow
either a logical grouping of like code:

/Model

/View

/Controller

Or use a naming convention: model1.js, view1.js, controller1.js
under a single folder. My Java and Rails projects follow the
convention above; A structured, opinionated layout. My Node

projects

follow the latter unless they use a framework that has it's own

opinionated structure.

I'd say with complex apps, MVC by folder groupings may be easier.
For small apps I'd keep it simple....

Pete Helgren
www.petesworkshop.com<http://www.petesworkshop.com>
GIAC Secure Software Programmer-Java
Twitter - Sys_i_Geek IBM_i_Geek

--
This is the IBMi Open Source Roundtable (OpenSource) mailing list

To

post a message email: OpenSource@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx Before posting, please

take

a moment to review the archives at
https://archive.midrange.com/opensource.

--
This is the IBMi Open Source Roundtable (OpenSource) mailing list To

post a message email: OpenSource@xxxxxxxxxxxx To subscribe,

unsubscribe,

or change list options,

visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx Before posting, please

take

a

moment to review the archives at https://archive.midrange.com/

opensource

.

--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/opensource.

--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/opensource.

--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/opensource.

--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/opensource.