Django Design Pattern for Large complex web app

Using Django Getting Started
1

I’m new to Django and have read numerous articles about constructing complex web-based applications that incorporate intricate business logic. We anticipate that the application, which we’re rewriting from scratch, will be substantial, involving processes that could take upwards of 300 pages with complex business logic

  1. What design pattern should be adopted in Django for effective architecture? For instance:

a. Should each model have a corresponding service layer (service.py) to facilitate the creation of reusable functions that can be utilized across different screens, as suggested on ilovedjango.com?

b. Alternatively, is it advisable to adhere to the concept of managers in Django?

c. Between the service.py and managers.py patterns, which is considered more reliable and maintainable?

d. Additionally, is it necessary to implement Dependency Injection, and if so, does this introduce performance issues? I came across a discussion on this topic at snyk.io related to the repository design pattern.

which can we maintainable, testable & better performance

1 Like
2

<opinion>
There aren’t any “universally accepted” patterns for large Django projects. For every individual proposing a “service layer”, you can find an equal number identifying them as unnecessary.

I’m in that latter camp.

Our flagship application consists of 9 apps with more than 120,000 lines of production code, using more than 125 models, a complete custom row-level security model, and a significant number of dynamically generated forms and views.

We have found no need to go beyond or outside Django’s standard project structure. We never even considered the implementation of a “service layer”, because we have never seen the need to extend Django in that direction.

The quality of the code being written on a per-function basis is a far greater factor in reliability and maintainability than any higher-level architectural pattern. Create your coding standards and enforce them rigidly.

I have never encountered a situation in Python where it is of value. (And yes, I have more than 5 years experience working in a Java / JavaEE / Spring, so I am familiar with the needs for it in that environment. However, the value for it comes from having to work around the limitations of Java, not because of any intrinsic value to the architecture itself.)

Again, the “tactical” decisions you make regarding specific function implementations are more important here than the strategic architectural decisions. Being truly proficient with Python gives you your best opportunities for success.
<opinion>

1 Like
3

ok thanks for the detailed explanation, so I can work on managing of required to extend the model I do have a couple of more questions.

  1. Do we need to have one model per app or we can have one app with all models created or grouped into logical relationships with different folders

  2. Am planning to use htmx for ajax posts in all forms to make feel async and avoid page refresh, is it ok or i need to write an ajax request manually for each, what would be the best approach?

  3. Can we use Raw sql only for large and complex and for normal select and update e, delete use form, will that be a problem in the future while scaling, using 2 ways of managing db access?

  4. also i tried Ajax form post, now how do we attach multiple models in a single form in Django and show in UI and do post and validation using ajax, the form needs to be single but the fields inside that form will come in various form

  5. I tried Abstractbaseuser but i would need the auth and authorize mechanism to handle dynamically from the table base don each URL so that i can handle that in middleware, rather than going with the decorator on each function in view, is it fine can we write entire auth and authorize without using auth.contrib and its middleware?

4

See:

I have personally fallen in love with HTMX and wouldn’t even think of starting a project now without it.

I don’t think I’ve ever used raw SQL for a Django model. We use the ORM exclusively.

Do not confuse a Django Form with an HTML <form>. You can render multiple Django Forms within a single HTML <form> tag. See Prefixes for forms.

I’m sorry, I don’t understand what you’re trying to say here.
(You do need to check authorization on each view. It doesn’t make sense in Django to do anything else.)

5

I don’t think “service layers” are a good idea in Django. The ORM is already your “service layer”.

Some classic posts from others on this subject:

2 Likes
6

@KenWhitesell or @adamchainz thanks for the suggestion will use manager.

I also need help on the Django custom Permission & Groups Table / Model

7

Please do not tag individuals requesting assistance.

We are all volunteers here, answering questions as time, knowledge, and energy allows.

1 Like