Django.

Django is a high-level Python web framework built for rapid development and clean, pragmatic design. It follows the Model-View-Template (MVT) pattern.

Its key features:

• It comes batteries included, meaning common features ship with it. These include an admin interface, authentication and an Object-Relational Mapper (ORM) that maps classes to tables.
• It follows the DRY principle, short for Don't Repeat Yourself.
• It protects against common attacks such as SQL injection, cross-site scripting and cross-site request forgery.
• It scales to high-traffic sites. Its "shared-nothing" design means the parts share no state, so you can add database, cache or web servers.
• It suits both HTML sites and JSON APIs.
• It has a large community, ecosystem and documentation.

MVT splits a Django app into three parts: a model, a view and a template. In Model-View-Controller (MVC) terms, the controller is the framework itself, the URL dispatcher that sends each request to the right view.

• The model defines the data structure and the business logic tied to that data. It works with the database through the Django ORM, which maps classes to tables.
• The view holds the business logic for one request and acts as the bridge between model and template. It takes the request and returns a response.
• The template is the presentation layer, usually HTML. It defines how the data is displayed to users.

The URL dispatcher routes each request to a view. The view processes the request and works with the models. It then renders a template with the data, and Django sends the response to the user.

Django's Object-Relational Mapping (ORM) layer lets you work with the database in Python code instead of SQL. It maps each model class to a table and each object to a row.

Its advantages:

• One API works across all the supported database backends. This database abstraction makes switching databases easier.
• Queries use parameters, which protects against SQL injection.
• You write queries in Python syntax, and the ORM generates the SQL for you.
• Migrations manage the schema automatically as your models change.

urls.py decides which view handles a URL, and views.py holds the code that handles it. Keeping them apart lets you change a URL without touching the logic behind it.

urls.py is the router. Its urlpatterns list maps URL patterns to views, and Django calls the view of the first pattern that matches. A pattern can also have a name, so templates and code build links with {% url %} or reverse() instead of hard-coding paths.

views.py holds the view functions or classes. Each one takes an HTTP request, runs the business logic and returns an HTTP response. Here it queries the articles and renders a template with them.

# urls.py
urlpatterns = [
    path('articles/', views.article_list, name='article_list'),
]

# views.py
def article_list(request):
    articles = Article.objects.all()
    return render(request, 'articles/list.html', {'articles': articles})

A project is the whole Django application, and an app is a module inside it that handles one area of functionality. The project holds the settings, the configuration and the root URLs, and it contains several apps.

An app is a Python package for one feature, such as a blog or user accounts. You switch it on by adding it to INSTALLED_APPS. Because an app does not depend on one project, you can reuse it across different projects.

Apps should follow the single responsibility principle: each app has one clear purpose. A blog app should not also handle billing.

myproject/          # Project
├── blog/          # App
├── users/         # App
├── settings.py    # Project settings
└── urls.py        # Project URLs

Model fields are class attributes that define the data type and constraints of each database column. The field class also sets the default form widget and basic validation.

Common field types, as in the example:

• CharField stores short text, here up to max_length characters. TextField stores long text.
• DateTimeField stores a date and time. auto_now_add=True sets it when the row is first created.
• BooleanField stores true or false.
• ForeignKey and ManyToManyField link to other models, and a ForeignKey needs on_delete.
• EmailField checks for a valid email address. SlugField holds a short URL label, and unique=True makes it unique in the table.

class Article(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    published_date = models.DateTimeField(auto_now_add=True)
    is_published = models.BooleanField(default=False)
    author = models.ForeignKey(User, on_delete=models.CASCADE)
    tags = models.ManyToManyField(Tag)
    email = models.EmailField()
    slug = models.SlugField(unique=True)

A function-based view is a plain function that turns a request into a response, while a class-based view inherits from one of Django's view classes. For the URL configuration, as_view() turns the class into a callable.

def article_list(request):
    articles = Article.objects.all()
    return render(request, 'articles/list.html', {'articles': articles})

Function-based views are simpler and more explicit. You read the whole flow top to bottom, and you branch on request.method yourself.

from django.views.generic import ListView

class ArticleListView(ListView):
    model = Article
    template_name = 'articles/list.html'
    context_object_name = 'articles'

Class-based views provide more structure and reusability. Each HTTP method gets its own method instead of an if branch. Mixins, small classes whose methods several views inherit, share behaviour across views. The generic ListView above queries the articles and renders the template with attributes only, no methods.

The cost is that the flow is spread across parent classes you have to read.

Use a function for one-off or unusual logic. Use a class when the view follows a common pattern or shares code with others.