Diseño OO vs Diseño de Base de Datos
-
05-07-2019 - |
Pregunta
Supongamos que estoy desarrollando una aplicación para un distribuidor de productos en C #.
El distribuidor realiza los siguientes 3 tipos de transacciones:
(1) Sangría
(2) Vender
(3) Stock
Estoy diseñando mis clases de la siguiente manera:
public abstract class Transaction
{
}
public class Indent : Transaction
{
}
public class Sell : Transaction
{
}
public class Stock : Transaction
{
}
Ahora, si quiero guardar estos tres tipos de información en tres tablas separadas, ¿cómo debo diseñar mi capa DA?
¿Debo construir clases DA separadas como
(1) IndentDA
(2) SellDA
(3) StockDA
o una sola clase TransactionDA
y realice operaciones CRUD comprobando sus tipos utilizando los operadores de as / is
?
¿O qué más puedo hacer? ¿Alguna sugerencia?
Solución
Primero, si creó una clase única TransactionDA y verificó los tipos dentro de la clase para realizar operaciones CRUD, estaría violando el Principio abierto / cerrado , por lo que definitivamente no iré por ese camino.
En cuanto a las sugerencias sobre cómo lograr la construcción de su DAL, sugeriría seguir algunas publicaciones de blog sobre personas mucho más inteligentes que yo sobre lo que piensan sobre este tema.
El repositorio es el nuevo Singleton
Repository is Dead: Long Live Repository
La Noche de los Repositorios Vivos
La conversación continúa, creo, pero eso debería ayudarte a comenzar.
Otros consejos
Usaría un ORM como NHibernate y usaría sus capacidades de herencia de múltiples tablas y luego no tendría que preocuparme por ello.
Yo usaría los subtipos de entidad aquí. Cree una tabla para las transacciones (y, como dijo un cartel anterior, tal vez sería mejor un término diferente) y almacene todo lo que es común allí. Luego crea un " subtipo " Mesa para cada especialización. Estas tablas de subtipo deben tener la misma clave principal que la tabla principal (la "entidad fuerte") y los campos que son exclusivos de esa especialización en particular. Cada subtipo está relacionado con la entidad fuerte de manera individual, con una participación opcional en el final del subtipo y la participación requerida en el extremo de la entidad fuerte.
Luego, para facilitar la consulta, defina una vista que (externa) une la entidad fuerte con todos los subtipos de entidad para que pueda " ver " todo.
Aquí hay un ejemplo simple (y común) de cómo configurar esto:
create table Employee (
eid int primary key,
first_name text,
last_name text not null
)
create table Salaried (
eid int primary key,
annualSalaryUSD money not null
)
create table Hourly (
eid int primary key,
hourlyRateUSD money not null
)
Si sabe que sus datos están en tres tablas separadas, normalmente tendría tres clases de DA separadas.
Sin embargo, si sus tablas son exactamente iguales, entonces podría genere TransactionDA y simplifique su capa de datos. Solo haría esto si sabe que tendrá un gran volumen de transacciones y va a separar sus tablas en diferentes archivos o algo, de lo contrario, probablemente simplificaría las cosas y las combinaría todas.
No intentes crear un TransactionDA a menos que todos tus tipos de transacciones por separado sean extremadamente similares
Puede usar la inyección de dependencia, crear una clase DA para cada uno y hacer que todos implementen la misma interfaz ITransactionDA con sus operaciones CRUD.
public interface ITransactionDA
{
void Read();
void Update();
...
}
public class StockDA : ITransactionDA
{
//implement interface methods
}
Stock stock = new Stock(new StockDA());
Haré algo así
public abstract class DistributerTransaction
{
DistributerDA dataaccess;
}
public class Indent : DistributerTransaction
{
}
public class Sell : DistributerTransaction
{
}
public class Stock : DistributerTransaction
{
}
public abstract class DistributerDA
{
/*Read();
Update();*/
}
public class IndentDA : DistributerDA
{
}
public class SellDA : DistributerDA
{
}
public class StockDA : DistributerDA
{
}
Echa un vistazo a la Banda de 4 patrones de diseño .