RE: .NET with System i5 - where to draw the line was->RE: No givingupon System i

If you were referencing the RPG Chart Engine, take a look at the following
powerpoint I did for RPGWorld:
http://mowyourlawn.com/files/RPG_Chart_Engine.pdf

Page 9 shows the "framework" high-level overview in picture format and
briefly describes the process flow. Note that this doesn't really address
the topic of this thread and I could see where a picture would be highly
beneficial to help describe what we are typing :-)

HTH,
Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Booth Martin
Sent: Monday, October 08, 2007 1:01 PM
To: Midrange Systems Technical Discussion
Subject: Re: .NET with System i5 - where to draw the line was->RE: No
givingupon System i

Gosh I wish these sites, (which have really great code!) would also show
screen shot(s). I still need pictures to understand what is happening.



albartell wrote:

I think the business logic, controller whatever model talk overly

complicates things.

I agree it complicates things for very small apps, but we aren't talking
about developing apps for ma and pa shops that will last 5 years. We are
talking about developing apps that will last 10+ years without having to
rearchitect because a "new" technology or idea came out. Like Pluta was
alluding to, there's nothing new under the sun, just people that don't

know

what has already been.

where you draw the line between code that runs on the windows forms

client,

the asp.net server and the central as400 will vary from project to project
and also depends on your level of expertise.

The approach I like to take is determining how instrumental a particular
piece of technology will be in the big picture. For instance, I have my

RPG

Chart Engine at http://mowyourlawn.com that gives the ability to create
graph, pie, and other charts right from RPG. Behind the scenes I

interface

real-time with Java using data queues to pass info back and forth. I have
Java in the mix because there was a tool better suited to the job of
creating charts (i.e. Jfree.org). My digression point is this: Creating
charts is a lesser part of the overall big picture in application
development and is only involved in a fraction of all applications. Would

I

have liked to have it all native RPG creating those charts, yes. But it
wouldn't prove timely. That is the same way I would use .NET. Leverage

it

where RPG just doesn't work well or can't work period (i.e. drawing GUI's

on

a desktop), but don't let it take over any other areas where RPG could be
used (i.e. controller/business logic). By using RPG more extensively it
also shields you from the Microsoft model of switching things out ever
couple years. By having a thin layer on the PC there is much less to
test/convert for each new Windows OS and what not.

As Lukas's group has found, it is VERY do-able to create a "thin" (and

rich)

client that only knows how to display a page and communicate events back

to

the server. I have found the same thing in some stuff I am doing. The
kicker is that I have developed an architecture similar to Lukas's where

the

client code is less than 2000 lines total (I just counted them)! A lot of
that is due to the rich set of Java API's out there (i.e. I didn't have to
write any low-level socket stuff, but instead using Java's HTTP packages).

The best part about it is that you only have to write and distribute the
.NET or Java layer once. From there on out any programming changes (i.e.
flow of app or business logic) are done completely on the i5 without

having

to install any new code on the client. Really the only reason you would
have to update the client is if you wanted to add a new/different UI
control.

what with the prevalence of legacy and packaged applications, how many

programmers are involved in business logic programming? my guess is most
programming today involves giving users access to existing data or

building

small modular data capture and entry apps which are then meshed with the
legacy system. In cases like this, .NET is the ideal platform to work in.

In my days I have dealt with vibrant i5 companies that have new

programming

needs every day. It sounds like your impression of i5 companies are more
maintenance minded. I think we both need to realize both sides of the
fence.

If your company owns an i5 where all it's data and BL is stored, would you
appreciate the approach laid out in this email thread if it retained your

i5

investment and saved time/money in the long run? Or would you still be
doing .NET because of the short term gains? Maybe your company only needs

a

short term gain?? (quite possible)

Later,
Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steve Richter
Sent: Monday, October 08, 2007 11:34 AM
To: Midrange Systems Technical Discussion
Subject: Re: .NET with System i5 - where to draw the line was->RE: No
givingup on System i (was: I'm about to give up)

On 10/8/07, albartell <albartell@xxxxxxxxx> wrote:

Richard,

I read your article in IBMSystemsMag.com and frequently see posts of
your .NET love. I am curious to know if you have found a
"comfortable" spot in where to keep your business logic and controller
flow when using .NET and the i5?

I think the business logic, controller whatever model talk overly
complicates things. Better to just get in there and write the code.
.NET is free, it is available on every windows PC or server that connects

to

the as400, it is leading edge technology and there are terrific

improvements

in store for 2008.

where you draw the line between code that runs on the windows forms

client,

the asp.net server and the central as400 will vary from project to project
and also depends on your level of expertise.

what with the prevalence of legacy and packaged applications, how many
programmers are involved in business logic programming? my guess is most
programming today involves giving users access to existing data or

building

small modular data capture and entry apps which are then meshed with the
legacy system. In cases like this, .NET is the ideal platform to work in.

-Steve
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,

unsubscribe,

or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.