Мысли о моем подходе MVC (данные + домен + бизнес-логика). Newb - PullRequest
1 голос
/ 06 июня 2009

Я пишу медицинское приложение для выставления счетов и впервые использую MVC (Spring), поэтому изо всех сил пытаюсь найти подход, который кажется правильным. Мысли / комментарии будут оценены.

Мои "доменные" классы

  • Доктор
  • Пациент
  • Претензия
  • BusinessLogic

Мой контроллер классов

  • ListPatients
  • EditPatients
  • FindPatients
  • SubmitClaim

Мои классы репозитория

  • IPatientDao
  • IDoctorDao
  • IClaimDao

Мое приложение очень «тяжелое правило». Например, врачи не могут удалять пациентов других врачей. Пациенты не могут быть удалены, если им выставили счет за что-то.

Я думаю, что эти правила не должны быть зафиксированы в контроллерах, которые кажутся грязными, особенно если правило нужно было использовать в нескольких контроллерах. Точно так же я чувствую, что мои объекты DAO предназначены только для чтения и записи, а не для проверки. Как следствие, я создал объект BusinessLogic, у которого есть мозги. Поэтому я могу назвать что-то вроде:

businessLogic.deletePatient (пациент, врач); // возвращает истину / ложь и устанавливает сообщение

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

Мне кажется, это лучший способ держать все в порядке.

Хорошо или плохо? Что было бы лучше?

Ответы [ 2 ]

1 голос
/ 06 июня 2009

Я чувствую к архитектуре MVC ... здесь должен быть поток LAyers ....

a) Класс действия .. как у нас в Struts ... все параметры с веб-страницы должны обрабатываться в этом классе ... все проверки должны обрабатываться валидаторами форм ...

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

c) Слои DTO ... метод установки геттера для всех классов в вашем приложении ... может использоваться всеми слоями ... пациентами, счетами, врачами и т. Д. Может быть несколько примеров ...

d) Уровень DAO ... который взаимодействует с базой данных ... он может взаимодействовать с использованием Hibernate, JDBC и т. Д. ... содержит все запросы, записанные в них ... выполняет все операции кэширования и т. Д. ...

Так что слои

Действие вызывает бизнес-уровень, вызывая уровень DAO. DTO может использоваться всеми слоями, а также может отправляться в виде объекта запроса обратно на страницу JSP для отображения данных ...

1 голос
/ 06 июня 2009

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

Не думаю, что я бы преобразовал объект BusinessLogic. Слишком общий.

Если вы используете Spring, я хотел бы знать, могли бы вы лучше использовать аспектно-ориентированное программирование для применения ваших правил.

Я бы посмотрел, может ли поддержка пружин для JSR-94 помочь вам. Возможно, вы могли бы встроить сложное поведение в объекты, используя механизмы правил.

Лучший совет - прочитать главу и стих из рекомендованной Spring иерархии слоев:

  1. Struts Action
  2. бизнес класс ~ Весенний сервис
  3. Nix DTO - обычно не используется в Spring. Это остатки анти-паттернов из EJB 1.0.
  4. Рекомендуется DAO / репозиторий Spring. JPA держит вещи в общих чертах.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...