0

I'm still new to Django and am trying to understand and implement the "fat model, skinny view" pattern. It makes sense to me that a model should be self contained for re-usability though I don't currently see the use case for this particular model.

The model is a virtual machine for one of many cloud vendors. I have a polymorphic base model, VirtualMachine which defines all the fields. I also have a specific model, VirtualMachineVendor which implements the vendor specific control function for VirtualMachine. Examples would be vm_create() or vm_delete that handle the model creation or deletion as well as the management of the cloud resource.

The view mainly processes the request and sends that to the correct model method and preparing data for the template. I want to add functionality for creating a domain record using some independent python code which communicates with the cloud provider.

Question: Should the VirtualMachine model call this domain creation method or should this be something the View calls? In general, should a model be calling other model methods within the same or different app, or should the model return control back to the view after a call?

I've also been trying to make sense of these SO Q&A making mention of a service layer for these types of methods:

Proper way to consume data from RESTFUL API in django

Separation of business logic and data access in django

Related question: is it fair then to say that fat models refer to the methods associated directly with manipulation of the model data?

Brian
  • 642
  • 7
  • 18
  • I'm not sure what you mean by "domain record". Do you mean an instance of your VirtualMachine subclasses, or something related to it? – Daniel Roseman Mar 29 '19 at 14:02
  • I added more detail...the domain record would be created with the cloud vendor using some independent code which itself is not associated with the model. – Brian Mar 29 '19 at 14:28

1 Answers1

2

This is really pretty arbitrary. I personally wouldn't put any code that calls an external API into the model itself; apart from anything else, that would complicate testing, but more generally I would treat model methods as having the database as their only dependency.

If you like, this could go in a utils module.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895
  • I'm open to suggestions. Are you saying that instead of calling the API directly from the model, perhaps I should create another module and class which does the calling? Right now I have `Model -> API` whereas if I interpret correctly, you would suggest `Model -> CustomModule -> API`? – Brian Mar 29 '19 at 15:26