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.



This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].