Organizacion de archivos en proyectos

Hace tiempo que estoy programando y diseñando aplicaciones o sistemas web, y es una pelea constante entre programador y diseñador, sumado a mucho código mezclado lo que hace por lo general de esta una tarea bastante ardua, y en especial cuando hay que modificar algo. Toque fondo cuando me toco modificar algo que yo no había realizado, y con esa mala experiencia comencé a ver como podía organizar y mejorar ciertas cosas propias de esta profesión.

Estoy mostrando como organizo mis archivos ahora, dando un porque a cada cosa, obviamente que no es el orden ideal y que hay falencias, por eso me gustaria que cada uno de su opinion, muestre como ordena las cosas para poder ver diferentes opciones, comparar y luego adoptarlas para trabajar mejor.

Aclaciones:
Mi perfil es de programador, no de diseñador.
Se debe maquetar con xhtml + css valido.

He aqui el orden de las carpetas:
public_html
------> css
------> images
------> js
------> mmedia
------> config
------> clases
------> ------> datos
------> ------> negocios
------> ------> usuarios


Algunas carpetas se sobreentiende el contenido, pero es mejor que tengan una subdivicion, algun diseñador pueda dar una ayuda sobre la carpeta images y css.

js: Aqui hiran todos los javascript
mmedia: Aqui hiran todos los archivos que son multimedia, por lo general swf
config: Aqui van las configuracion en general, tambien los mensajes que se mandan en caso de error, nombres de botones, y esas cosas que el "cliente" desea cambiar.


Desde el punto de vista de programacion, la idea es el siguiente, separar una aplicacion web en 2 partes grandes partes, una donde trabaja el programador, y otra donde trabaja el programador en conjunto con el diseñador; cada parte estara divida en 2.

Parte 1: Datos
La capeta es clases > datos
Esto es puramente tarea de un programador, aqui estaran las clases necesarias para la conecion a la db mas no asi la configuracion (que estara en la carpeta config). Todo el trabajo con las base de datos (conecion, ejecutar consultas, devolver valores, etc) se encontrara en esta carpeta. La idea es que si tenemos un motor de base de datos, con cambiar las clases de esta carpeta sea suficiente para trabajar en otro motor de base de datos, sin tener que modificar algo de las demas clases.

Parte 2: Negocios
La capeta es clases > negocios
Esta segunda parte es exclusiva de los programadores, aqui se estableceran todas las reglas de negocios propias de la aplicacion o sistema, tambien realizara las verificaciones pertinentes con las base de datos (que un valor no se repita, etc), tambien es la parte encargada de realizar la consulta sql que se va ejecutar en la base de datos y decide si se usan o no transacciones.

Parte 3: Usuario
La capeta es clases > usuario
En esta parte trabajan junto el programador con el diseñador. Aqui se encontran todas las validaciones de lo que el usuario ingresa (letras, numeros, caracteres validos, etc), tambien es la encargada de recibir los formularios y enviarlos a la parte de negocios, muestra listados, muestra formularios, etc.

Parte 4:
La capeta es la carpeta raiz, en mi caso public_html
Esta parte es casi exclusiva del diseñador, obviamente como su nombre lo indica, se encontrara todo el XHTML que vera el usuario y se incluirá la menor cantidad posible de código de lenguaje de servidor. La idea es dejar el XHTML lo mas limpio de código posible.

La parte 3 y 4 puede ser confuso de ver, así que voy a dar un pequeño ejemplo.

Mostar un formulario de alta.

Para mostrar un formulario de este tipo, estamos tentados a pensar en dejarselo encargado a la parte 4, pero yo prefiero que este en la parte 3 por varios motivos.
Comprension del codigo: Si bien el codigo es XHTML, hay cosas que debe definir el programador (nombres, etc) y es preferible no dejar esa tarea a los diseñadores xq' no es su tarea.
Claridad del codigo: En la capa 4 se puede poner algo como

Código :

 <?php $obj->armar_formulario() ?> 

y listo, tanto el diseñador como el programador saben que ahi hay un formulario, al diseñador le sirve para maquetar y diseñar y al programador le sirve para tener control del formulario.

Mostar un formulario de modificacion.

Se sigue el mismo razonamiento que con el formulario anterior, aca con mas razon ya que en los inputs hay que poner datos.

En ambos casos, cuando se recibe el formulario para procesar se puede hacer algo como

Código :

 <?php $obj->trabaja($_POST); ?> 

y con eso podemos enviar el formulario junto con sus datos de la parte 4 a la parte 3, para que el programador lo sepa trabajar.
Lo bueno de esto, es que si el programador tiene que modificar algo del formulario no necesita al diseñador para que coloque las cosas en el xhtml, y si el diseñador tiene que cambiar algo del xhtml, no se debe preocupar por otras cosas.

Bueno ese es mi orden que tengo actualmente. Opiniones, comentarios y demases, ya saben que hacer.

La verdad exelente tipo de orden tienes Dientuki. Me gusto y lleva bien la relacion con el diseñador. Opinare mas mas tarde al ver las opiniones de los demas.
Mis respetos

En verdad no hay un estandar para estructura de archivos en los proyectos, pues depende de cada proyecto y todas las estructuras se pueden adaptar a cualquier proyecto en verdad pero algunas resultan ideales para un tipo de proyecto mientras para otros no.

Hay estructuras de archivos para proyectos grandes, medianos, pequeños. Al menos ese que presentas parece uno de proyecto mediano.

saludos

Es irán, sin H, ya que viene de 'ir'

En mi caso la carpeta 'datos' se llama ADODB (para no reinventar la rueda)

En realidad, es imposible evitar que un diseñador dañe algo de código que no entiende, ya sea por que su editor no lo soporta o mil cosas más.

Si tratamos de evitar el 100% de esas situaciones, terminamos haciendo algo como J2EE y trabajar será tedioso y aburridor.

Lo mejor es usar un sistema de control de versiones como Subversion y así nunca habrán cambios fatales, ya que todo estará documentado y se sabe exactamente que líneas fueron modificadas y corregirlas realmente es trivial en un 99.99% de los casos.

Y concuerdo con Maikel, hay que adaptar la organización del proyecto al tamaño del mismo.

Mi orden es practicamente el mismo, salvo que no utilizo una carpeta "clases", aunque en mi caso es principalemente porque no trabajo con PHP e iría en su lugar una carpeta "bin" con una dll o jar.

Como normalmente mi capa de presentación se comunica con un servicio web, a lo sumo hay una dll proxy que llama a la lógica que se mantiene en otro servidor. Pero como bien dice Maikel, depende del tipo de proyecto, la tecnología que vayas a implementar y otros factores.

Una estructura que estoy utilizando en algunos proyectos que implementan el Model2 o MVC, es justamente crear una carpeta por proyecto orientado a Modelo, Control y Vista, que permite separar cada una de las capas de la aplicación.

Coincido con Dani.Shorei, usar un manejador de control de versiones, tipo CVS o SVN ayudará bastante, pero principalmente, en el tema de sincronizar tu trabajo con un diseñador, es un tema de, a mi parecer, manejo de proyecto.

No hay una necesidad que el diseñador toque las páginas que está haciendo un desarrollador. Puede bien diseñar un template con CSS y la estructura básica de la página y el desarrollador puede verificar su código mediante pruebas unitarias, con plantillas sencillas ya hechas para verificar el flujo. Luego se aplican las hojas de estilo y listo, tenemos integrado contenido con diseño.

Y algo que olvidé mencionar, que tiene de aburrido y tedioso J2EE? . Si lo usas de la manera adecuada y para el fin adecuado, todo bien

Por eso uso CakePHP (MVC) y vivo feliz... aunque nunca he hecho un proyecto conjunto asique mi opinión realmente no vale mucho
Pero defiendo el uso de frameworks... aunque no los he visto en proyectos grandes.

En mi caso, en proyectos grandes puedo decir que el 90% han sido utilizando frameworks. Y el 10% restante era por necesidades muy específicas del cliente e incluso así, se utilizó como base algún framework.

Usar un framework es una muy buena práctica, ya sea un framework externo o uno propio. El tiempo de desarrollo se reduce bastante, así como el número de errores y nos permite concentrarnos en la lógica de negocio. Normalmente, habrán los frameworks que trabajan con una estructura de directorios específica (Ruby on Rails, por ejemplo) y otros que son más "libres" (ASP .NET, por ejemplo) -hablando, obviamente, "out-of-the-box".