Change tracking is never really required, web app or not. It s a nice feature that can be very useful depending on the object model of your application, but it is no where near required. Effectively using change tracking can add a lot of complexity to an application and make debugging significantly more challenging. It has the ability to significantly increase the initial speed of development however.

Like most decisions, it s situational.

Why do you think that web applications are stateless? Shopping carts are not stateless, banking applications are not stateless ... any web site other than purely read-only sites are not stateless. Even read-only sites may have caches, ie. state which can change on each request.

I suspect that we are not quite speaking about the same thing when we use the terms "stateless" and "change tracking". In an attempt to clarify, let s take an example, Room Booking:

User X books a room for a meeting with user Y by entering some data and hitting submit

    the system makes some entries in a database

User Y wants to change the time of the meeting, enters some data and hits submit

    the system amends the data (and tells user X)

So the room "state" has changed in both cases. Do we need change tracking? I assume that we are talking about in some way keeping a record of who made the changes? An audit trail. The answer to that question is not technical, it s down to the business meaning of the change. Here it s a low value action, probably we don t care. But imagine a different business case, one dealing with payments of millions of pounds. The actual pattern of interaction could be the same User X specifies the payment, user Y changes it. Suddenly we really care about who did what and who said what.

In summary, Web Apps are no different from any other app, the individual interactions may or may not maintain conversational state, but useful web apps (like any other) do change system state. The decision about what to audit is a business decision.

This is really more of a requirements question than a coding question. However, you may want to leave your options open on this one -- the requirement to detect conflicting changes may only materialize once someone gets burned. :-)

A simpler (business, not technical) question would be: does anyone need to audit changes on the site? Usually, even for many sites that currently don t implement change tracking, the answer is YES --- a disgruntled employee or an abusive user could delete or change information , and there needs to be a way to track down the responsible person, the change, and the version before.

Web applications may be stateless, but they are definitely not linear. Especially concerning products, inventory, and order tables: make sure you are aware of concurrency issues and how 2 people can be trying to get the same inventory at once. Logging can be the most effective way of seeing concurrent interactions in a web app.

So no, don t just tell the repository "update this instance". Start a transaction, get a lock on the row of data, run your update, confirm everything worked, then commit.

I think there s some confusion being introduced by the way you ve phrased your question.

Change tracking within the context of an ORM typically refers to the data. From the responses to the other answers, you re referring to Schema versioning.

Whether this is a necessity or not depends entirely on the context of your environment.

If you entirely control the database and the webapp, and have the freedom to control deployments to the environments in which they both run - then it may not be necessary.

If you re working within a larger system or organisation, management of deployments or changes to both may not be as easy - and so it may be necessary to have your applications work with older versions of the schema for some time.

My idol have the precise answer.

http://weblogs.asp.net/fbouma/archive/2007/04/03/why-change-tracking-has-to-be-part-of-an-entity-object.aspx

Don t forget that web-application is just UI. If you have separated business logic layer with relatively complex logic, you may need change-tracking there. But if you work on simple read-only application like stackoverflow.com, you definitely don t need change-tracking.

By the way, Michael Maddox s answer can also make sense, you can live without without change tracking at all if you want.