Вывод бизнес-логики с уровня доступа к данным

Question

Мы пишем некоторые приложения поддержки (довольно небольшие) в нашу систему ERP.

Таким образом, до сих пор я чувствую, что использую уровень доступа к данным для двух ролей: бизнес-уровня и доступа к данным.

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

Так что мне нужна помощь, чтобы определить, что к чему.

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

GetProductAvailabilitybyItem

GetProductAvailabilitybyLot

и т.д.

Если мне нужно, чтобы отделить их, что я должен делать?

Другое дело, что в моей голове заключается в том, чтобы нормализовать мой DAL и заставить его каждый раз возвращать разные сущности (через один общий метод получения), я должен был бы использовать DataTable в качестве возвращаемого типа. В настоящее время я использую такие вещи, как List<PalletRecord> как типы возврата.

Я чувствую, что мои приложения настолько малы, что трудно (и, возможно, бесполезно) различать эти 2 слоя.

Моя основная потребность - создать что-то, что может быть использовано несколькими интерфейсами (веб-страницы, WinForms, WPF и т. Д.).

Дополнительный пример:

Поговорим немного штрих-код. Мне нужно проверить, действительна ли принятая запись лота или нет. Я беру запись в DAL и создаю метод, возвращающий bool в бизнес-слое?

Затем я могу вызвать метод bool из любой презентации, чтобы проверить, содержит ли текстовое поле допустимый лот?

Является ли это чрезвычайно упрощенной логикой?

Answer 1

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

Пример, который вы предоставили, помогает поддержать эту идею, хотя и довольно упрощен.

Ответ Pablo также предлагает некоторые хорошие дизайнерские идеи: вы должны обязательно использовать ORM, чтобы упростить DAL и держать его очень тонким. Я нашел NHibernate and Fluent, проделать отличную работу. Вы можете использовать BL для координации доступа с использованием объектов доступа к данным.

Answer 2

Учитывая, что вы имеете дело с очень маленькими приложениями, почему бы просто не использовать ORM для обеспечения доступа к данным и просто беспокоиться о бизнес-слое?

Таким образом, вам не нужно беспокоиться о том, как обращаться с DataTable, отображать данные на объекты и все такое. Гораздо быстрее развивается, и вы уменьшите размер кодовой базы.

Например, NHibernate или Microsoft, Entity Framework

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

Answer 3

Я не являюсь большим поклонником архитектуры nTire и имею некоторые веские причины для этого.

Главная цель для такой архитектуры

• Возможность работы с различными подстилающей разделения базы данных
• контекста - то есть разработки приложений и бизнес-логики Однородность и
• подтверждение лучших моделей и практик.

Однако, делая так, вы также сделать некоторые жертвы, такие, как отказаться от провайдера конкретных оптимизаций и т.д.

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