Создаете ли вы классы для обработки “сущностей” для приложений, управляемых данными?

Question

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

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

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

Answer 1

ДА.

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

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

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

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

Для ASP.Net в ObjectDataSource Объект - источник данных возможно, стоит присмотреться.Сам я им не пользовался, но в Интернете есть множество образцов.Попробуй здесь или здесь.

Answer 2

ДА.

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

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

Answer 3

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

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

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

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

Вначале это кажется дополнительной работой, но она того стоит.