Использование DataTable на уровне пользовательского интерфейса вместо сущностей

Мое базовое трехуровневое приложение состоит из DAL, который общается с моим BLL, а BLL взаимодействует с пользовательским интерфейсом.

До сих пор я использовал старомодный способ построения DAL с помощью программ чтения данных и команд обновления/вставки. Это сработало хорошо, потому что большинство моих потребностей, где читать.

Теперь мне нужно все больше и больше для обновления информации о базе данных и проверки параллелизма. Я думаю об использовании таблиц данных, чтобы сделать мой пользовательский интерфейс более гибким при редактировании и сохранении данных в таблицах БД.

Теперь у меня есть List<InventoryItem> в моем пользовательском интерфейсе, и всякий раз, когда мне нужно, я отправляю этот список в BLL-> DAL, чтобы внести свои изменения.

На мой взгляд, я думаю, что мне придется сделать так, чтобы мой BLL возвращал данные в пользовательский интерфейс, чтобы мой пользовательский интерфейс легче реагировал на обновления?

Моя главная проблема заключается в том, как логически связать трехуровневую логику (UI-BLL-DAL) с преимуществами модели DataAdapter/DataSets/DataTables...


person e4rthdog    schedule 06.02.2013    source источник


Ответы (1)


На первый взгляд это кажется правильным, но это просто разрушит многоуровневую архитектуру. Перенося типизированные наборы данных (datatable) до UI, вы просто позволяете UI напрямую использовать CRUD операции. Тогда нет необходимости использовать другие слои.

Это просто разрушит абстракцию.

Использование N-уровневой архитектуры — это выбор, использовать ее или нет, зависит от ваших требований. Может быть, сначала нужно определиться, действительно ли вам это нужно; и если вы не можете придумать правильное рассуждение, вам не нужно его использовать.

person daryal    schedule 06.02.2013
comment
Я понимаю. Послушайте, мне нужен многоуровневый подход. У меня могут быть простые приложения, но их довольно много для решения различных проблем домена. Поэтому я хочу иметь надежный DAL и BLL и соответствующим образом применять свой пользовательский интерфейс (Forms, WPF, WCF и т. д.). Насколько я понимаю, если мне нужен доменный/многоуровневый подход, я должен либо использовать традиционные устройства чтения данных и т.д. или перейти на ORM? - person e4rthdog; 06.02.2013
comment
ИМХО, переход на ORM может быть полезен в зависимости от размера и требований проекта вместо использования подхода чтения данных. - person daryal; 06.02.2013
comment
На этот раз размер не большой. Одна таблица для чтения/записи и чтения из 5-6 таблиц, чтобы получить правильные данные для записи... Просто хотел изучить, что происходит в отношении подходов. Я думаю, что это либо устройства чтения данных, либо ORM... - person e4rthdog; 06.02.2013
comment
тогда общее количество таблиц в базе данных ограничено максимум 6? - person daryal; 06.02.2013
comment
Да, один в SQl Server, а другие в AS400 DB2, используемые для выбора значений и подготовки данных для таблицы сервера sql. - person e4rthdog; 06.02.2013
comment
Ключевым словом здесь является AS400 DB2; Я бы определенно посоветовал вам использовать считыватели данных. - person daryal; 06.02.2013
comment
Я бы не стал использовать другие устройства чтения данных в AS400. Но вопрос заключался в том, что верхний уровень (пользовательский интерфейс) должен использовать наборы данных для чтения и записи в единственную таблицу SQL-сервера. Думаю, я выберу DTO и устройства чтения данных... Спасибо. - person e4rthdog; 06.02.2013
comment
В моем предыдущем комментарии я хотел не использовать инструменты ORM с DB2, поскольку вы не найдете слишком много поддержки, если возникнут какие-либо проблемы. - person daryal; 06.02.2013