nospam said:
Still missing one important aspect.
Search and replace works just as good as OOP...
Sure, search and replace works really well, until you've forgotten to search
and replace one piece of your application. With N-Tier development, I
modify it in one place, compile, send it to my users and they plug it in. I
don't even have to bother other "production" components that are dependent
on my changes. Which one is easier to maintain now?
It's a proven tool that applications like Word, NotePad, and even VS.NET
have built in....
What you don't realize is that all the apps you've said also expose COM
components that applications can take advantage of. These components are
also easily used for N-Tier development.
I could easily have a bunch of the SAME methods all over the place that can
be easily "SEARCH and REPLACED" a LOT FASTER than the OOP abstracted, all in
one place N-Tier or 3-Tier design.
Like I said, in N-Tier design, I modify the method I need to change and no
more search and replace for me. Which one is a lot faster... What if you
have to modify a whole code block? Damn, you're lucky if you're using
Regular Expressions so you can include CRLF characters on your text. What
you gonna do? Replace each occurrence of a certain command in your code,
line per line. Hmmm, business rule contains 10 lines of code (at least),
across 10 pages. Wow a 100 times you'll have to do cut and paste. Regular
Expression cut and paste style... figuring out the regular expression in
the find string and applying the correct one to the replace string... good
luck!!!
I guess since it's SO simple to use, OOP people don't even want to mention
it because they have less work or would be out of a job...wouldn't want the
manager to know it was so simple would you.
It's simple to use, yeah... But, the reason why it's not mentioned by most
OOP programmers is because it's just plain "STUPID." Knowing if we design
it well, we only need to change it in one place.
Nevertheless, no one here said business logic was built directly INTO the
PDA. BUT Gurus, authors, MVP's, etc keep touting it in the Architecture of
Web Sites, server side, by saying, "Oohhhhh, because we have a middle tier
and our business logic can easily work with "different" presentation
layers......Uhhhhh...did it ever occur to you that different presentation
layers mean totally different USER Needs???????? Translation.....a lot
simplier, (which means different) business logic layer.
Let me "Cut and Paste" what you indicated in your reply...
Don't deny what you wrote... and if you are, you're just contradicting what
you say. And if you contradict yourself, then your word as a "contributing"
member in a group of developers is not to be taken seriously. Your words
"as such for use in PDA's" suggest that you're thinking of putting the
business tier in it (just plain stupid as an idea though).
And to answer your question of different presentation layers are different
functions... NOT!!! Given an example of a simple (note the word simple)
Time And Attendance application. There is only one goal of the enterprise
app. That is, to log in the time the employee got in and out. Yet,
software companies have written a Web GUI, Voice Recognition Telephone
systems and swipe cards. Although these interfaces are different, all their
underlying rules are the same. For example, the employee cannot come in to
work before 7:00 AM. Despite the interfaces are different, they all follow
the same rule. Now, assuming you go with your 2-Tier design... the company
decides to change the rule to 8:00 AM... Wow, modification on 3 UI's. So,
where's the difference in the user's needs in this scenario? Take the
example of a retail application, since your major use for the internet is to
buy things. A company may open a website to sell their items, a 1-800
service over the phone and a retail store. In case you want a solid
example, take pizza hut as one. It has all three means of getting to the
customer... (Pizza hut is working on a central site, where people in one
location can take the order and forward it to their regional stores.) All
the rules are the same, you make your order, get charged and tax is added
into it plus other fees. Yeah, the rates may be different but if you design
it differently, you'd just grab it from the database and feed that
information to the interface. Even though each GUI may have additional
features, the basic rules of doing business still applies.
Man, this feels weird, it's like teaching a high school student to break bad
habits!!!
THE FACT that YOU ACCEPT BUGS as a WAY of LIFE for SOFTWARE
means your NOT INNOVATIVE as YOU THINK YOU ARE.
At least I'm smart enough to realize that not everything in life is perfect.
To assume that it is is plain stupid. And because of this assumption, I
find a constant role in correcting the imperfection and making people's life
better.
WHERE IS THAT IMAGINATION YOU keep talking about???????
However, bugs are not the only reason to issue updates and patches. You can
improve performance as technology becomes better. For a simple minded
person's sake... Consider that he created software that used, bubble sort
algorithm inside a method. Later on, he found out that a quick sort
algorithm will make his application work better... making the change on the
DLL across all applications that used his component is easier than changing
all the applications with that logic. EVEN WITH CUT AND PASTE!!!
What's the use of the riddle? And it's seems to be missing another "O."
There is a lot more where this came from.......
As we wait, there will be more revealed bugs, patches that break other
patches, and fixes that unfixes other fixes.
Can you say honestly, that you've never changed your application once it
went to production. Or do you call it an entirely different product every
new release...
Oh well, so much for ENCAPSULATION when patches break other patches...but
then that's OK with you since you, Mr. INNOVATION, have accepted bugs as a
fact of life.
Yes, I have accepted bugs as a natural fact of life... and so is famine and
war and every little evil in this world. Not to accept it is to live a
false life. But should that stop me from putting out my patches or getting
them, the answer is definitely NO. In a digital world, no matter how secure
your application is, it's just plain nonsense to think that you are safe
from every hacker in this world. Nor should you assume that your
application works perfectly. One should design their system for growth,
adaptation and presentation. Perfection, is a false goal. As a seasoned
developer, I know that not everyone can be satisfied by your work. And
that's why, patches are released one right after the other. Why is it, that
Norton AntiVirus and McAffee, producing updates to their systems? They are
afterall, somewhat reliable. That's because it's a never ending battle.
Besides, life does not stop because your application has been rid of bugs.
You can constantly improve on it, give it more features and make it more
user friendly. Like I said, fixing bugs is not the only reason why you
issue a patch. Now, isn't that innovation? But I guess, I have to thank
you for calling me as such. (NOT!!!)
Here's the real plus of N-Tier design that I keep on forgetting to include
in my past messages. N-Tier development allows me to concentrate more on
building the application rather than spending time on the "infrastructure"
of my product. If you don't understand that, you can read up on Microsoft
DNA or J2EE development. They'll explain to you what I meant.
As for the moment, J2EE has the better infrastructure than Microsoft. Only,
Microsoft has the better IDE than most J2EE compliant tool I've used before.
That includes JBuilder... really need to improve it a whole lot more to
come par with Visual Studio. And if you think Microsoft has a patch every 2
months or so, JBuilder has a new version every 3 to 6 months. My point is,
no matter what technology you use, you'll constantly encounter bugs in the
system. Even the "glorified" mainframe applications have bugs. Remember,
Y2K? Now, that's a perfect example of how hairy it was to modify 2-Tier
applications. (As most COBOL programs have that very nature.) If it were
an N-Tier architecture... as I did with my clients... all I needed was a
patch from microsoft and modified one module. Beat that with your cut and
paste!!! (And yes, the companies continued to operate even after Y2K.)
I come to wonder, how do you build "internationalized" versions of your
applications. It must be a gruesome task to change its feature from english
to spanish to french. Oh, I can just imagine the currencies and the dates
(in case you didn't know, some countries use comma's instead of dots in
numbers, and dots instead of slashes)... Thinking of how to do it in a two
tier application gives me the horror of doing everything ALL OVER AGAIN on
the same logical code. That is one piece where your "CUT" and "PASTE"
wouldn't work too well... Still convinced that your favorite "CUT" and
"PASTE" will do the job? Don't ask me how, but for seasoned developers
(it's a trade secret for N-Tier developers and OOP programmers)... this is
an easy task with OOP and N-Tier development. Having a different method for
each language is not even necessary if you design it right. Just remember,
after it is all said and done, currency representation and dates, no matter
what the culture is, are all represented the same way in .NET at the end.
to work with logically