He estado investigando esto durante semanas. Actualmente estoy diseñando un diseño de arquitectura flojo usando el método n-tier (3 capas) y el enfoque de diseño de fábrica. Mi objetivo es poner la lógica de negocios de cada cliente (ClientA.DLL, ClientB.DLL) en espacios de nombres separados para que el proyecto se amplíe, lo que significa que puedo modificar/eliminar/agregar la lógica de negocios de un cliente específico sin afectar a los demás, porque son no dependientes el uno del otro. Luego invoco los espacios de nombres/clase del cliente utilizando el identificador único del cliente (un valor de cadena que se mantiene en la base de datos) a través del espacio de nombres de fábrica. El Factory.DLL también oculta la lógica por cliente, mientras que el BusinessAbstract.DLL sirve como el Diseño o la Plantilla que utilizarán las clases por cliente.Creación de una arquitectura de software escasamente acoplada/escalable
Aquí está la solución de proyecto:
Y aquí es el código real:
BusinessAbstract.DLL
namespace BusinessAbstract
{
// the entity/data transfer object
public class MemberDTO
{
public string MemberID { get; set; }
public string MemberName { get; set; }
}
// the interface
public interface IMaintainable
{
void Add();
void Edit();
void Delete();
}
// the base abstract class, implements the Entity and the Interface
public abstract class Member : MemberDTO, IMaintainable
{
// Implement IMaintanable but change it to abstract
public abstract void Add();
public abstract void Edit();
public abstract void Delete();
// a method with Database access, get from DAL
public virtual MemberDTO GetMemberDetails(params object[] args)
{
return DAL.MemberDAL.FetchMemberDetails(args);
}
public virtual string GetClientBLL()
{
return "base's method";
}
}
}
aplicación cliente A de la AbstractBusinessRule
ClientA.DLL
namespace ClientA
{
public class _Member : BusinessAbstract.Member
{
public override void Add()
{
throw new NotImplementedException();
}
public override void Edit()
{
throw new NotImplementedException();
}
public override void Delete()
{
throw new NotImplementedException();
}
public override string GetClientBLL()
{
return "ClientA Method";
}
}
}
La fábrica
Factory.DLL aplicación
public static class Invoker
{
public static T GetMemberInstance<T>(string clientCode)
where T : Member, IMaintainable
{
Type objType = Type.GetType(clientCode + "._Member," + clientCode);
return (T)Activator.CreateInstance(objType);
}
}
Muestra el nivel de presentación
la Web
protected void Page_Load(object sender, EventArgs e)
{
// invoke Member class using String hardcode
Member obj = Invoker.GetMemberInstance<Member>("ClientA");
Response.Write(obj.GetClientBLL()); //prints clientA method
obj = Invoker.GetMemberInstance<Member>("ClientB");
Response.Write(obj.GetClientBLL()); //prints clientB method
}
Y también se dará cuenta de que tengo una carpeta DAL en cada una de las DLL del cliente, así como la AbstractBusinessRule DLL, porque también quiero escalar la capa DAL y el uso de la estructura de capas "IU-BLL -DAL ".
Cualquier comentario/sugerencia sobre este diseño es bienvenido. Espero recibir sugerencias sobre cómo puedo mejorar esta estructura. Gracias por adelantado.
¿Alguien puede decirme si el objeto de dominio es un término más o menos común que DTO? Solo pregunto porque nunca había escuchado hablar de DTO, pero la mayoría de la gente sabe a qué me refiero cuando digo domain object, y creo que eso es lo que hace el DTO. –
Sí, creo que es solo un nombre antiguo del dominio./Objeto comercial o entidad. Valor Objeto que es ... – CSharpNoob
DTO == objeto de transferencia de datos, pero no creo que el OP lo esté usando de esa manera. Especialmente teniendo en cuenta que los DTO generalmente no hacen mucho más que almacenar los datos para pasarlos, por lo que no es como si pusiera lógica de negocios allí o inicie operaciones de persistencia desde allí. – eglasius