Script de la base de donnée

CREATE TABLE users (
    id               INT CONSTRAINT PK_user PRIMARY KEY IDENTITY,
    pseudo           VARCHAR(30) CONSTRAINT UK_user_pseudo UNIQUE NOT NULL,
    firstName        VARCHAR(30) NOT NULL,
    lastName         VARCHAR(30) NOT NULL,
		mail             VARCHAR(100) CONSTRAINT UK_user_mail UNIQUE NOT NULL,
    phone            VARCHAR(15) NOT NULL,
    street           VARCHAR(255) NOT NULL,
    postalCode       INT NOT NULL,
    city             VARCHAR(100) NOT NULL,
		password         VARCHAR(50) NOT NULL,
    points           INT,
)

CREATE TABLE articles (
		id               INT CONSTRAINT PK_article PRIMARY KEY IDENTITY,
		idSeller         INT CONSTRAINT FK_article_seller REFERENCES users(id) NOT NULL,
		name             VARCHAR(30) NOT NULL,
		description      VARCHAR(MAX) NOT NULL,
		categorie        VARCHAR(30) NOT NULL,
		image            VARBINARY(MAX),
		startDate        DATE NOT NULL,
		endDate          DATE NOT NULL,
		startingPrice    INT NOT NULL,
		street           VARCHAR(255) NOT NULL,
		postalCode       INT NOT NULL,
    city             VARCHAR(100) NOT NULL,
		bestOffer        INT,
		idUserBestOffer  INT CONSTRAINT FK_article_bestOffer REFERENCES users(id),
		pickedUp         BIT,
)

Structure du modèle

Le modèle de données de l'application OSNA est organisé en trois couches principales :

• Data Access Layer (DAL) : Gère l'accès aux données et la communication avec la base de données.
• Business Object (BO) : Définit les objets métier "User" et "Article".
• Business Logic Layer (BLL) : Contient la logique métier de l'application.

Pour maintenir une séparation claire entre ces couches, nous utilisons les concepts suivants :

• Factory Pattern : Utilisé dans la DAL pour créer des instances de manière centralisée.
• Singleton Pattern : Employé dans la BLL pour garantir une seule instance de certaines classes métier.

Nous gérons également les messages d'erreur dans un package "messages" avec des codes d'erreur constants et des fichiers .properties pour stocker les messages associés.

Cette structure simplifie la maintenance et assure la cohérence de l'application.