Бизнес-объект [закрытый] дизайн DAL
Чтобы реализовать внешний интерфейс в объекте ATL, нужно
- добавить интерфейс в список реализованных интерфейсов (вы это сделали). Это изменит двоичное расположение класса (vtable и т. Д.)
- и добавит интерфейс в список
BEGIN_COM_MAP. Это даст команду ATL, лежащему в основе реализацииQueryInterface, ответить положительно на запросы для этого идентификатора интерфейса (вы это сделали).IUnknownздесь не нужно. - добавить объявление интерфейса в файл .h. Связи и аннотации там необязательны, я лично их удаляю. Я также всегда добавляю примечание с именем интерфейса, чтобы мы знали, какой метод используется каким интерфейсом. Когда у тебя много, это полезно ...
- добавить реализацию интерфейса в файл .cpp.
Так что в вашем случае это будет для файла .h:
class ATL_NO_VTABLE CExternalConTest :
public CComObjectRootEx<CComSingleThreadModel>,
public CComCoClass<CExternalConTest, &CLSID_ExternalConTest>,
public IExternalCon // change the class layout
{
public:
...
BEGIN_COM_MAP(CExternalConTest)
COM_INTERFACE_ENTRY(IExternalCon) // answer to QueryInterface calls
END_COM_MAP()
...
public:
// IExternalCon
HRESULT GetName(ULONG *interface);
...
// IWhatever
HRESULT Blabla( ... );
HRESULT Blabla2( ... );
...
и для файла .cpp:
// CExternalConTest
...
// IExternalCon
HRESULT CExternalConTest::GetName(ULONG *interface)
{
// TODO : implement this
return S_OK;
}
...
// IWhatever
HRESULT CExternalConTest::Blabla(...)
{
// TODO : implement this
return S_OK;
}
HRESULT CExternalConTest::Blabla2(...)
{
// TODO : implement this
return S_OK;
}
Относительно .idl вам не нужно ничего делать, потому что Visual Studio использует его в качестве основы для генерации кода. Обычно при использовании Visual Studio вы сначала изменяете .idl (используя мастера или нет), а затем заполняете пробелы.
6 ответов
Я положился в большой степени на статью NHibernate Best Practices Billy McCafferty / пример кода для многих сеть / приложения WinForms теперь. Это - замечательно написанная статья, которая предоставит Вам хорошую твердую демонстрационную архитектуру - в дополнение к обучению Вам основной NHibernate и TDD. Он пытается дать Вам обзор своей архитектуры и проектных решений.
Он создает очень изящный DAL с помощью универсального DataAccessObjects, который можно расширить для каждого объекта области - и его очень слабо связанный к интерфейсам использования BL и DAOFactory. Я рекомендовал бы смотреть на BasicSample сначала, особенно если Вы не работали с NHibernate прежде.
Отметьте, эта статья полагается в большой степени на NHibernate, но я думаю общий подход, это могло быть легко изменено для удовлетворения другому ORMs.
К сожалению, я не думаю, что существует "лучший путь", это слишком зависит от определенной ситуации относительно того, какой подход DAL Вы используете. Большим обсуждением "состояния" являются Шаблоны Архитектуры приложений для предприятия Martin Fowler.
Глава 10, Источник данных Архитектурные Шаблоны конкретно говорит о большинстве обычно используемых шаблонов для бизнес-приложений.
В целом, хотя, я нашел использование самого простого подхода, который встречается, основные требования пригодности для обслуживания и адаптируемости лучший выбор.
Например, на недавнем проекте простой "Шлюз Данных строки" был всем, в чем я нуждался. (Это было просто сгенерированными классами кода для каждой соответствующей таблицы базы данных, включая методы для выполнения операций CRUD). Никакие бесконечные дебаты о ORM по сравнению с сохраненным procs, это просто работало и сделало необходимое задание хорошо.
Существует несколько общих шаблонов. 'Шаблоны архитектуры предприятия' книга являются хорошей ссылкой для них:
- Шлюз данных таблицы
- Шлюз данных строки
- Активная запись
- Картопостроитель данных
При использовании ORM, такого как llblgen, Вы получаете выбор самообслуживания или адаптера.
Если бы Вы спускаетесь по маршруту NHibernate (хорошая ссылка на статью BTW от @Watson выше), то я настоятельно рекомендовал бы что Вы контроль демонстрационный проект suvius-фламинго от codebetter. У него есть очень хороший, сжатый, демонстрационный проект, который показывает MVC и NHibernate в действии.
Я собираюсь предположить, что Вы означаете писать DAL, который получает доступ к SQL, потому что это - наиболее распространенная часть сегодня. ТОТ, если самые большие проблемы в записи DAL против SQL часть ORM. Таким образом, существует фундаментальное несоответствие импеданса между программированием OO и схемами реляционной базы данных. Были многие великие, успешные даже, попытки записи ORMs. Но они все страдают от той же проблемы, которая является их преимуществом: они абстрагируют Вас далеко от базового сгенерированного SQL. То, почему это - проблема, то, что производительность Вашей базы данных является критическим компонентом как хорошо Ваши системные функции в целом. Много ORMs (возможно, большинство) не только имеют меньше звездную производительность для многих стандартных запросов, но и на самом деле поощряют шаблоны использования, которое значительно ухудшит производительность (пересекающий отношения неоднократно в циклах при запросах наборов, являющихся одним типичным примером, делая разрешение мертвых блокировок трудным являющийся другим). Конечно, после изучения API ORM подробно, можно обычно находить способы вокруг этих выбоин производительности.
Мое текущее взятие на состоянии ORMs - то, что я хочу, чтобы это сделало как можно меньше, все еще давая мне эффективность солидной библиотеки, которая заботится обо всех основных деталях доступа к данным. Другими словами, потому что я не думаю, что они "достаточно хороши" все же и никогда не могут быть с SQL как бэкэнд, я хочу сохранить контроль на уровне без операционной системы, и я буду выпадающий к записи SQL вручную без колебания во многих случаях, независимо от ORM, потому что я знаю особенный метод, я хочу, чтобы данные были запрошены для моих данных потребностей.
Это - очевидно, более хрупкий подход к кодированию чем при религиозном использовании ORM, как это было предназначено, так в результате необходимо быть дополнительны прилежный с точки зрения поблочного тестирования, Внедрения SQL и надлежащего разделения проблем. Так, таким образом, я соглашаюсь с Ash, хотя это не подразумевает, что он соглашается со мной :)
[обновление] это больше не действительно, дизайн этого проекта, было изменено [/обновление]
В нашем Bunian проекта с открытым исходным кодом мы пришли к заключению, что Бизнес-объекты (целый компонент) являются ядром системы, и все должно вращаться вокруг этого включая тот уровень доступа к данным.
Бизнес-компонент продиктует другим, в чем он нуждается, подразумевая это через интерфейсы. Например, у Человека Бизнес-объекта будет интерфейсный участник под названием IRepositoryForPerson, этому участнику присвоят экземпляр через контейнер Внедрения зависимости при необходимости.
Для получения дополнительной информации проверьте мое сообщение в блоге здесь:
http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design//
и проверьте код Bunian здесь (хотя это любительски все же):
http://www.codeplex.com/Bunian
Конечно, там будет появляться новые вещи с этим подходом как жизненный цикл сессии доступа к данным (если Вы будете использовать NHibernate, например). но это было бы для другого вопроса, который я предполагаю :)
я надеюсь, что Вы находите это полезным