Thoughts on my MVC approach (data + domain + business logic). Newb

Question

I'm writing a medical billing application and am using MVC (Spring) for the first time so I'm struggling to get an approach that feels right. Thoughts/comments would be appreciated.

My "domain" classes

• Doctor
• Patient
• Claim
• BusinessLogic

My controller classes

• ListPatients
• EditPatients
• FindPatients
• SubmitClaim

My repository classes

• IPatientDao
• IDoctorDao
• IClaimDao

My application is very "rule heavy". For example, doctors can't delete the patients of other doctors. Patients can't be deleted if they have been billed for something.

I think these rules should not be captured in Controllers, which feels dirty, especially if a rule needed to be utilised in several controllers. Similarly, I feel my DAO objects are for reading & writing only, not validation. As a consequence, I have made a BusinessLogic object which has the brains. So I can call something like:

businessLogic.deletePatient(patient,doctor); //returns true/false and sets a message

This does a check to see if the logged-in doctor has the right to delete a specific patient.

To me this seems the best way of keeping everything tidy.

Good or bad? What would be better?

Answer 1

The domain model looks hopelessly naive to me, because it doesn't include anything for dealing with insurance companies or an interface for an accounts payable/receivable system. But maybe you're at an early stage and just trying a simple model before you build it up.

I don't think I'd reify a BusinessLogic object. Too generic.

If you're using Spring, I'd wonder if you could take better advantage of aspect-oriented programming for applying your rules.

I'd look into whether or not Spring support for JSR-94 could help you. Maybe you could embed complex behavior in objects using rules engines.

The best advice is to read chapter and verse from Spring's recommended layering idiom:

1. Struts Action < Spring Controller;
2. business class ~ Spring service
3. Nix the DTOs - not typically used in Spring. They're leftover anti-patterns from EJB 1.0.
4. DAO/repository is recommended Spring idiom. JPA keeps things generic.

Answer 2

I feel for a MVC architecture... here should be the flow of LAyers....

a) Action class..like we have in Struts...all the parameters from webpage should be handled in this class... all validations should be handled by validators of forms...

b) from this action class call your business class which does all the busniess logic for a given action .... say billing patients ... this will get the doctors associated with it and say give some comission to doctors for that ...

c) DTO layers...getter setter for all classes in ur application ... can be used by all the layers ... patients, Bills, doctors, etc can be few example...

d) DAO layer..the oe whihc interacts with the databse... it can be interacting using hibernate, JDBC etc ... has all the queries written in them ... do all the caching stuff etc...

So the layers are

Action calls the Business layer call the DAO layer ..DTO can used by all layers and can be also send as a request object back to the JSP page for displyaing data...