A liitle history / opinions on this application architecture?

[Serenarules]

Many of you may remember I had quite a time moving to PHP from vs.NET about a year ago. I have spent a good deal of time in study and have even asked a few questions here recently. Here's the story. I haven't worked professionally since just before the 9-11 incident. If you recall, the industry was suffering at that point and I lost my position due to cutbacks. Since the collapse and following events, I was evicted, lost my vehicles, had a son die (emotional effect), and other things to boot. Being self taught, and years out of practice, I find it impossible to get hired now. As a result, I want to start my own modest contracting agency but I was stuck between a rock and a hard place. I could not afford the newer Microsoft IDE's and really didn't want to learn another language. Well, I had to pick one, so I did. It's been a long road, but I think I've arrived. I haven't said much up until now because I didn't want to become discouraged at some point along the way. Just before the demise of my last official position, we were working on a distributed application for a major company. While I have no client to speak of at this point, I though that starting small, and working up to the point where I could duplicate that appliaction in PHP, would be a grand thing for me to do. Not only in a capacity for customization and sale, but for my own self esteem. Here is where I lay it on the line, to see if I have grapsed the concepts of a distributed PHP application. Be honest, but constructive in your replies.

----------

The basic application specs were:

- Database split into two. One hosues only raw data, the other userland settings.

* The reason for this is because there may be many UI's for the app and each needs to define it's own display settings and options.

- Modular service system. Modules may be placed on several servers.

* I selected web services for this need and build them around a common include file and a class repository so that the services could share classes internally while retaining the ability to expose only what's needed to the outside.

- Provide a client kit so that various web UI's can be built quickly.

* I selected simple customized SoapClient wrappers for this and a simple MVC design.

- Provide a service mapper so that a client app can be updated quickly to new service locations.

* I used a simple associative array here mapping service names with urls to wsdl files. This is tied into why I used SoapClient wrappers.

----------

So basically we now have an application that has both display and logic completely seperated at the code level, but in regards to the database as well. Each client UI may have it's own local database for language, phrases, templates, settings and options, while they all share the same content database.

----------

I made decent, but not overdone, use of singletons and patterns, as well some linear function code that just didn't need encapsulation. Even in a static class, it would've been overkill. Likewise, I used arrays where I could. They take less resources to instantiate. I make use of no globals, sanitize all input and output, and use inheritance where truly beneficial. Use of interfaces is slim as there wasn't much need. The skeleton app works like a charm, but I want to wait until I have a fully worked up example before I share the url. So shoot. Did I do a decent job based on the description?

[siteartwork]

This all sounds good to me, however, hearing the theoretics is somewhat different from seeing this bugger work in practice

- Database split into two. One hosues only raw data, the other userland settings.

* The reason for this is because there may be many UI's for the app and each needs to define it's own display settings and options.

This is something I don't get at first: Let's say you have a webserver on which this app is running for 5 customers: Would you have all in all 10 databases then or 1 db housing raw data, 5 dbs housing userland data? Do you need 1 db for each ui?

I'd like to hear about the development process: What kind of techniques where used (UML, Testing etc.), how many ppl where working on this? What kind of databases do you support and: What goal is this application aimin at?

[Serenarules]

This is something I don't get at first: Let's say you have a webserver on which this app is running for 5 customers: Would you have all in all 10 databases then or 1 db housing raw data, 5 dbs housing userland data? Do you need 1 db for each ui?

One content database per company. One userland database per division (however the company decides to implement this is too various to list). The is so the UI developed for managers has only what they need and is logical for them to use. Employees may see a very different portion of the data via their own UI. I won't be hosting any part of this for a client.

What kind of techniques where used (UML, Testing etc.)?

Honestly? ee: it's a console based text editor for FreeBSD. I have no GUI on all but one machine. I haven't gotten to proper unit testing yet. It's on my TODO list.

How many ppl where working on this?

When I was employed back when, about 10 MS certified people, myself included.
Now, just me in my spare time.

What kind of databases do you support?

The DA layer is abstracted, but currently only a mysql connector is written.

What goal is this application aimin at?

First and foremost, to see if I can pull it off in PHP. Secondly, give me the confidence to start offering paid IT development services again. This particular application may never see a client. It's kind of silly really, but I based it's content on the d20 system of dice based RPG's. Mainly because there's a lot of raw data aailable to plug into it and various client UI's to be written (player, DM, etc...). I don't think it would be legal to sell this one. It's a learning tool, all practical evolutions aside.