Что касается вашей необходимости ссылаться на бизнес-уровень из DAL, я согласен, что это, вероятно, не оптимально - нижние уровни не должны знать о тех, что над ними, это снижает возможность повторного использования и добавляет дополнительные / потенциально циклические зависимости.
Рассматривали ли вы, чтобы ваши бизнес-объекты «наполнялись» и выполняли свои собственные операции сохранения с использованием классов DAL, вместо того, чтобы DAL действовал для них как фабрика (как в вашем текущем проекте)? Таким образом, ваш DAL будет более прямым представлением базы данных, а бизнес-объекты будут содержать (бизнес-логику), необходимую для надлежащего заполнения и сохранения.
Кроме того, указанный вами слой «BLL» на самом деле не кажется мне содержащим бизнес-логику; мне кажется, что это больше уровень сервисов сохранения для сущностей.
Итак, вариация того, что вы предлагаете, может быть:
- Интернет / пользовательский интерфейс, ссылка на бизнес-объекты
- BusinessEntities, содержит интерфейсы и классы с бизнес-логикой. Слой ссылок DataServices
- DataServices, содержит классы, которые загружают, находят и сохраняют данные. Может обслуживать «общие» структуры, содержащие данные (объекты передачи данных), которые могут быть созданы, потреблены и обработаны бизнес-объектами. Ссылки DAL.
- DAL, который просто предоставляет классы, которые сопоставляются с таблицами.
В зависимости от ваших требований, я бы рассмотрел возможность объединения ваших BusinessEntities и DataServices (BLL в вашем первоначальном дизайне) в один уровень; единственная причина, по которой я могу придумать, чтобы разделить их, - это если вы делаете что-то вроде Silverlight, где вам нужны асинхронные операции с данными на клиентских бизнес-объектах.
Конечно, все это происходит при неполном знании ваших конкретных системных требований - вам нужно будет разработать то, что лучше всего подходит для вашего конкретного приложения. Удачи!
person
Guy Starbuck
schedule
08.04.2009
