Архитектура API

Я нахожусь в процессе разработки API. Я хотел бы знать, является ли то, что я придумал, хорошим решением:

У меня есть уровень данных репозиторного типа, который взаимодействует с базой данных путем преобразования бизнес-классов в сущности (сгенерированные из LLBL GEN, я не сделал этого) Я не хочу использовать сущности непосредственно в качестве бизнес-объектов, потому что я хотел, чтобы они были простыми и позволяли мне переключаться на Entity Framework или какой-либо другой сопоставитель, который мне нужен)

У меня есть уровень службы WCF, который я использую как вид фасада. Он вызывает уровень репозитория и преобразует бизнес-объекты в DTO и передает их через вызов службы API через сообщение клиенту. Клиент может быть веб-сайтом ASPX, приложением Silverlight, приложением WPF или даже приложением WP7. Проблема, с которой я постоянно сталкиваюсь, заключается в том, что когда я хочу запустить бизнес-логику, мне нужно отправить DTO обратно в службу WCF, а затем обратно клиенту. Мне это не кажется "правильным". Я не могу добавить бизнес-логику в DTO, потому что это противоречит цели. Но если я хочу, чтобы код бизнес-типа запускался на клиенте, у меня много дублирования кода на разных клиентах.

Мой бизнес-уровень не знает об уровне данных, мой уровень данных знает о бизнес-уровне, а мой фасадный уровень знает об уровне данных, бизнес-уровне и DTO. Это плохой дизайн для API? А может кто-нибудь предложить мне какие-нибудь предложения? Я узнал о приложениях корпоративного уровня только из чтения различных статей в Интернете.

Спасибо!

5
задан BoltClock 20 December 2010 в 15:49
поделиться