Python MVC – File Separation Best Practices

code-qualitydesign-patternspython

I'm used to programming in Java, so my view of these things is quite Java based but I doubt this is the correct way of writing Python code. I found this https://stackoverflow.com/questions/106896/how-many-python-classes-should-i-put-in-one-file link which asks a similar question to what I am about to ask.

In Python, when creating an MVC application, does it make sense to put all the classes in one file (module) as each part of the MVC application does technically belong together?

In Java, the idea would surely be to split these files as we might want to swap out either part of the MVC combination for another part. That is one of the advantages of writing MVC code (though in practice, might happen rarely). Still, I would opt to create a file for each part of the MVC code. A class for the model, view and controller.

Now, I can kind of get grouping objectGUI, objectModel, objectController in one module. As together they form object. But on the other hand, that feels kind of wrong from the Java background.

Is there a good rule of thumb for how splitting into modules actually works in Python. Is MVC even a strong thing in Python? (In my mind, Python is still mostly for glue code and scripts).

Best Answer

In Python, a file is a unit of import. So it makes sense to put things that belong together in the same file, and things that don't, to separate files.

Web frameworks like Django by default expect you to put your models in models.py, and your views / controllers in views.py. In large applications, these files are actually split, usually by subject area. Django also allows you to compose a whole web app from several reusable 'applications', each with its own structure.

It is easy to split a large file into several files without breaking existing code in Python. You just re-export the names from a split-out file, like this:

(views.py)

# These used to be defined here, now moved to premium_views.py 
from premium_views import FancyFeatureView, ExtraSnazzyView

class StandardView(...): ...

Now you can from views import FancyFeatureView, as if it were completely defined there. There's even a pattern of having such files that only re-export things from a bunch of other modules, so that these other modules can be changed as authors see fit without affecting normal client code.

Another consideration could be testing. What you want to test under significantly different setups likely belongs to different modules (files).

Related Solutions

Python – Getting Variables from Other Modules in GUI and MVC

You're on the right track. The controller is what binds the app together, so passing it around to the various view and model classes is fine.

However, don't think that just because you have a controller, all widgets must use that controller for everything. For instance, I wouldn't put the onclick method in the controller. The controller should be for routing business logic, but what you're doing is mostly specific to the GUI.

I think a good general rule of thumb is that GUI events and callbacks should be within the GUI module. They then call the controller when interfacing with business logic. Fetching a string from the GUI itself is not business logic.

So, instead of:

# GUI module
button = Button(..., command=controller.on_click)

# Controller module
def on_click():
    var1 = GUI.widget_entry.get()
    self.do_something(var1)

I would do this:

# GUI module
button = Button(..., command=on_click)
def on_click():
    var1 = widget_entry.get()
    controller.do_something(var1)

With the above, the controller doesn't need to know what widgets are part of the GUI. All it does is provide an interface through which the GUI can request services.

If you prefer to keep the on_click in the controller, that's possible too, and not completely unreasonable. However, instead of building in knowledge of the GUI widgets into the controller, give the GUI an interface that the controller can use.

For example, instead of doing GUI.widget_entry.get(), the controller would call an accessor such as GUI.get_entry_widget_value(). That allows you to refactor the GUI without having to change the controller. If you move the entry to the_widget_entry instead of widget_entry, the controller can be completely unaware and still function properly.

Python Code Quality – Is It Pythonic to Have Multiple Classes in One File?

It's fine. It's fine in C++ as well, for reference.

Keeping tightly-coupled things together is sensible practice. Avoiding inappropriate coupling is also good practice. Striking the right balance isn't a matter of strict rules, but of, well, striking a balance between different concerns.

Some rules of thumb:

Size

Excessively large files can be ugly, but that's hardly the case here. Ugliness is probably a good enough reason to split a file, but developing that aesthetic sense is largely a matter of experience, so it doesn't help you figure out what to do a priori
Separation of Concerns

If your concrete implementations have very different internal concerns, your single file accumulates all those concerns. For example, implementations with non-overlapping dependencies make your single file depend on the union of all those dependencies.

So, it might sometimes be reasonable to consider the sub-classes' coupling to their dependencies outweighs their coupling to the interface (or conversely, the concern of implementing an interface is weaker than the concerns internal to that implementation).

As a specific example, take a generic database interface. Concrete implementations using an in-memory DB, an SQL RDBMS and a web query respectively may have nothing in common apart from the interface, and forcing everyone who wants the lightweight in-memory version to also import an SQL library is nasty.
Encapsulation

Although you can write well-encapsulated classes in the same module, it could encourage unnecessary coupling just because you have access to implementation details that wouldn't otherwise be exported outside the module.

This is just poor style I think, but you could enforce better discipline by splitting the module if you really can't break the habit.

Best Answer

Related Solutions

Python – Getting Variables from Other Modules in GUI and MVC

Python Code Quality – Is It Pythonic to Have Multiple Classes in One File?

Related Topic