Вы создаете классы для обработки «сущностей» для приложений, управляемых данными? - PullRequest
2 голосов
/ 05 мая 2009

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

Теперь, когда я немного развился, скажем, что я продавал виджеты покупателям и сохранял информацию о продажах в базе данных. Если бы я писал программу для доступа к базе данных, не хотел бы я создать класс типа «Клиент» и «Виджет» для работы с этими объектами?

Если я ошибаюсь, тогда какой подход к программированию приложений баз данных?

Ответы [ 3 ]

4 голосов
/ 05 мая 2009

Да.

Вы хотите изучить n-уровень программирования.

По сути, вы разрешаете внешнему интерфейсу (уровень представления) доступ только к вашей библиотеке классов (бизнес-уровень). Затем ваша библиотека классов обращается к вашей базе данных.

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

Что касается связывания, если вы используете Windows Studio Forms (начиная с 2005 года), вы можете использовать bindingSource , который затем можно использовать для привязки ваших элементов управления. Если вы используете ASP.NET, тогда ваш элемент управления должен без проблем связываться со списком объектов.

Для ASP.Net ObjectDataSource может стоить изучить. Я сам этим не пользовался, но в интернете много примеров. Попробуйте здесь или здесь .

2 голосов
/ 05 мая 2009

Да.

Вы хотите присмотреться к объектно-реляционному сопоставлению .

Ваши реальные бизнес-объекты моделируются объектами, которые отображаются на реляционные таблицы.

1 голос
/ 05 мая 2009

Вы не хотите, чтобы уровень презентации напрямую зависел от структуры вашей базы данных; проблема в том, что если ваша структура базы данных вообще меняется, уровень представления должен измениться, и в долгосрочной перспективе это может вызвать проблемы. Кроме того, существуют проблемы безопасности, связанные с непосредственным взаимодействием уровня презентации с вашей базой данных.

Грубая аналогия здесь с рынками; когда вы идете в магазин, чтобы купить буханку хлеба, вам не нужно знать, как выращивать пшеницу; все, что вам нужно знать, это то, что у вас есть деньги, и у них есть хлеб, и что они обменяют определенное количество хлеба на определенную сумму денег. Вам не нужно знать, в какое время года сажать пшеницу, или как удалить шелуху, или что-то в этом роде, потому что защитный слой позаботится об этом за вас. Точно так же фермеру не нужно знать, как продавать хлеб целой группе людей или даже как делать хлеб; все, что он должен сделать, это знать, как вырастить пшеницу.

Современная философия дизайна рекомендует использовать промежуточный уровень для взаимодействия между уровнем представления и уровнем базы данных; это где вы положили свою бизнес-логику. Например, предположим, что вы продаете виджеты на своем сайте. Вместо того, чтобы ваш код представления запрашивал в базе данных виджеты и отображал их, у вас есть бизнес-объект, который обрабатывает ваши виджеты. Таким образом, ваш бизнес-объект должен знать, какова ваша структура базы данных, но вашему уровню презентации нужно только знать, как запросить у вашего бизнес-объекта список виджетов для отображения. Что еще более важно, в вашем бизнес-объекте вы можете разместить правила, которые должны вызываться, когда происходят определенные вещи. Таким образом, вместо того, чтобы ваш уровень представления непосредственно вносил изменения в базу данных для инвентаря и заказов при оформлении заказа, ваш бизнес-объект знает, как внести изменения и какие таблицы изменить, когда ваш уровень представления запрашивает продажу.

Таким образом, вы отделяете отображение вашей информации от постоянства и логики, лежащей в основе сайта. То, что вовлечено, является хорошим планированием; в частности, вы должны выяснить, что ваш веб-сайт будет делать в любой момент, и что это означает с точки зрения того, какие интерфейсы будут предоставлять ваши бизнес-объекты. Затем вы реализуете свои бизнес-объекты на основе этих требований; в эти бизнес-объекты вы помещаете знания о структуре базы данных и вашей конкретной бизнес-логике («когда происходит A, делайте B, а затем C» и т. д.).

Поначалу это кажется большой работой, но оно того стоит.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...