Я занимаюсь этим неделями. В настоящее время я проектирую свободно-связанную архитектуру с использованием метода n-уровневого (трехслойного) и заводского дизайна. Моя цель - разместить бизнес-логику каждого клиента (ClientA.DLL, ClientB.DLL) в отдельных пространствах имен, чтобы проект масштабировался, что означает, что я могу изменять/удалять/добавлять бизнес-логику конкретного клиента, не затрагивая других, потому что они не зависят друг от друга. Затем я вызываю пространство имен/класс клиента, используя уникальный идентификатор клиента (строковое значение, поддерживаемое в базе данных) через пространство имен Factory. Factory.DLL также скрывает логику для каждого клиента, в то время как BusinessAbstract.DLL служит в качестве макета или шаблона, который будут использоваться классами для каждого клиента.Создание слабосвязанной/масштабируемой архитектуры программного обеспечения
Вот решение проекта:
А вот фактический код:
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";
}
}
}
Clientâ реализация 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";
}
}
}
Фабрика
Factory.DLL реализация
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);
}
}
образца на уровне представления
Веб-сайт
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
}
И вы также заметите, что у меня есть папка DAL в каждой из библиотек DLL клиента, а также AbstractBusinessRule DLL, потому что я хочу, чтобы масштабировать DAL слой и использовать структуру слоя «UI-BLL -DAL «.
Любые комментарии/предложения по поводу этого дизайна приветствуются. Я надеюсь получить информацию о том, как я могу улучшить эту структуру. Заранее спасибо.
Может ли кто-нибудь сказать мне, является ли объект домена более или менее распространенным термином, чем DTO? Я просто спрашиваю, потому что раньше я никогда не слышал о DTO, но большинство людей знают, что я имею в виду, когда я говорю объект домена, и я думаю, что это то, что DTO .. –
Да, я думаю, что это просто имя старой школы для домена/Бизнес-объект или объект. Объект Value, который есть. – CSharpNoob
DTO == объект передачи данных, но я не думаю, что OP использует его таким образом вообще. Специально рассматривая DTO, как правило, не делают ничего, кроме хранения данных, которые должны быть переданы, поэтому его не так, как вы вкладываете в него бизнес-логику или начинаете с него операции сохранения. – eglasius