Re: PHP site development

From: Tony Marston (tony_at_NOSPAM.demon.co.uk)
Date: 07/11/04 

Date: Sun, 11 Jul 2004 12:29:04 +0100

"Me" <jdangler@atlantic.net> wrote in message
news:pan.2004.07.11.01.48.19.323931@atlantic.net...
> Man, did start something here, or what?
> Tony~
> I may be new to PHP, but not to the development world in general. I am
> still struggling a bit with the architecture which you laid out in your
> site, but I think I can latch onto it.

Every new architecture looks complicated at first. It is only by running the
sample code that you can follow the logic and judge if it is suitable for
you. The next step is to create a new database table and see how long it
takes you to create components which can maintain it.

> I'm a little amazed at how large
> a can I opened by asking the question.

It just goes to show how varied opinions can be and that there is no "one
true architecture". Different people try to reach the same objective in
different ways, each with their own level of complexity, efficiency and
scalability. It is your choice as to which one you use - unless of course
you become an employee in an organisation and they force you to adopt their
choice.

> I've been on both the front end
> and the back end of a number of projects, and I have to agree that
> re-usable components are the shortest distance between two points. I
> have been a developer on a number of RAD projects ('Crunch Mode') they
> used to call it, and have seen teams struggle with the scratch built
> concept. I do believe that the front end should be seperated from the
> back end as much as possible, and I have been in meetings where
> programmers were let go because it was discovered that an application
> under development would not scale to the clients end requirements.

I was once on a project where the system architects (who were supposed to be
my superiors) designed and built an infrastructure that in theory was
absolutely brilliant. It contained all the right buzzwords (3 tier
architecure, separate application model for te presentation layer, object
oriented design) but sufferred from one minor flaw - it took two weeks to
build each individual component. The client was so impressed by the effect
on his bufget and his timescales that he cancelled the whole project.

To me the effectiveness of an architecture is not how many buzzwords you can
use when describing it, but how quickly you can develop components with it.
I have designed and built development infrastructures in 3 different
languages and I have consistently achieved development times in hours or
minutes rather than days or weeks.

> As to the site that I have inherited, the colors were chosen by the
> executive officers, so that's a wash. I do know that the display is not
> being presented uniformly across platforms (a problem which I'm not sure
> how to resolve at the moment),

If you stick to pure (X)HTML and simple CSS, and avoid such things as
javascript and ActiveX controls, you should have a site that renders the
same whatever browser is being used - provided that it is a browser that
conforms to the current W3C standards.

> but, with all of the different sections
> (and four more to be added), and the addition of the services and
> supplements sections, I know first-hand that this site has already grown
> well beyond the point of manual maintenance. I need to get the
> redevelopment underway and would like to implement your architecture to
> do so, since there are other parts of the site (mapping, user tracking,
> site search, etc) that need to be integrated, and will only make a
> horredndous maintenance job that much more complicated. My point in the
> earlier post was that, as a data entry/maintenance app, the sample
> presents the ideas you have quite well, but the site that I need to work
> on has only the view side to contend with at the moment (although,
> administration of all that data is certainly one which has to be
> tackled). I'm continuing my review of the subject matter on your site
> in hopes that the light goes on giving me a starting point (which, my
> guess is at the database level designing the tables and relationships
> ws which will house the data for the site). Any thought are greatly
> appreciated.

The most important part of any application is the database design - if you
get that wrong you are screwed from the start. Then you need a class for
each database table (business entity) that contains the business rules for
that table/entity. Then you construct components (utilising as many
pre-written reusable modules as possible) to display and maintain the
contents of those database tables.

Easy peasy lemon squeezy. 

-- 
Tony Marston
http://www.tonymarston.net
> On Thu, 08 Jul 2004 14:35:43 +0100, Tony Marston wrote:
>
> >
> > "Leythos" <void@nowhere.com> wrote in message
> > news:MPG.1b5708502083e7b898a77c@news-server.columbus.rr.com...
> >> In article <ccj5vi$39f$1$8300dec7@news.demon.co.uk>,
> >> tony@NOSPAM.demon.co.uk says...
> >> > The disadvantage of using a team comprised of offshore members that
have
> >> > never worked with you before is that you have to train them to
produce
> > code
> >> > to the project standards, otherwise it will be incompatible with what
> >> > everyone else is writing. This is true whether you have a framework
in
> > mind
> >> > or not. Having a suitable framework is only half of the equation -
you
> > need
> >> > developers who are familiar with that framework so that when a new
> > project
> >> > comes along they can hit the ground running.
> >> >
> >> > This is my experience after 20+ years working in software houses.
> >>
> >> This is my experience too - the framework requires training, and
> >> maintenance, which you must figure into the overhead, which you must
> >> figure into the hourly rate....
> >>
> >> We're on the same page, frameworks are great, but there are downsides
to
> >> them also - more than just training.
> >
> > Just try develping an application without any sort of framework to start
> > with and you will be in a bigger mess. You then have to develop a
framework
> > AND train all your staff how to use it.
> >
> > If you keep using new staff on each new project you will have to train
them
> > each time, framework or no framework. You can get better savings by
reusing
> > the same team of developers who are then able to reuse the same
framework.
> > If you start from scratch with each new project then your start-up costs
> > will always be much higher. So you can achieve the highest savings by
having
> > a reusable framework AND a reusable development team.
>

Relevant Pages

  • Re: OOP - a question about database access
    ... >> and not an existing database is IMO the correct approach. ... > design and OO design evolve almost in parallel (or course DB design can ... send method calls to modify the needed object data in memory ... theory offset the losses incured by a framework based memory-to-DB transactional ...
    (comp.object)
  • Lead .NET Architect role in UK (contract or permanent)
    ... architecture design for enterprise web services environment, ... underlying code and framework into web services into XML. ... infrastructures, logging services, design interfaces on a unit/test ...
    (microsoft.public.dotnet.general)
  • Re: limit of lines?
    ... > Agreed, but don't let database design influence OO design, the two are not ... My framework has several rules ... > Customer ID ...
    (borland.public.delphi.non-technical)
  • Re: limit of lines?
    ... And this is the fundamental mistake in your design. ... a objects from a database, this usually leads to very poor design. ... Framework in which all properties are backed, not by a simple field, but by ... we have major size projects that use the Delphi template ...
    (borland.public.delphi.non-technical)
  • Re: Just say no to threads [Was: Software architecture]
    ... standard Java I/O was not adequate, so the architecture was refactored ... to incorporate java's "nio" or new I/O framework. ... incorporating heavy duty frameworks right away, ...
    (comp.object)