Q:

What is the LOP_INSERT_ROWS and LOP_DELETE_ROWS operation on a View object?

I'm examining the MS SQL Transaction Log for investigating a problem, and found there are a huge amount of LOP_INSERT_ROWS and LOP_DELETE_ROWS operations on a SQL View object within a single "user_transaction" last for over a minute.
I just curious what is the meaning of a LOP_INSERT_ROWS and LOP_DELETE_ROWS operation on a View object? Do they mean the action on creating and dropping a View object? 
Thanks.
[Updated on 2016-05-12]
The following is the user_transaction (0000:0f20ab9b) I mentioned above. It starts at 10:00:12 and ends at 10:01:44. It generated over 3,000,000 transaction log operations within ~1.5mins. The 99% of first half of this transaction are the LOP_DELETE_ROWS operation on the PartitionId=72057594040877056, and the 99% of second half of this transaction are the LOP_INSERT_ROWS operation on the same PartitionId.

Hence, I checked the object name and id belonged to this PartitionId=72057594040877056 by the following query, and the query show it is a user view object (id=125243501).

Does anyone saw this symptom before?
[Update on 2016-05-25]
The view definition is shown below:
CREATE  VIEW [dbo].[get_xxxxxxxxxxxxxxxxxxxxx_vw]
WITH SCHEMABINDING
AS
    SELECT  Apple.rr_id, Apple.r_date, Apple.r_num, Apple.rr_num,
            Apple.h_code, Apple.j_code, Apple.t_code,
            Apple.is_scratch, Apple.result, Apple.is_replaced,
            Apple.draw, Apple.weight, Apple.rating, Apple.gear,
            Orange.s_id, Banana.p_id,
            Orange.l_index, Orange.e_index, Banana.c_key,
            Grape.price, Grape.ss_id, Grape.price_time, Grape.price_trend, Grape.choice_id, 
            Banana.c_id
    FROM    dbo.Apple, dbo.Pear, dbo.Orange, dbo.Grape, dbo.Banana
    WHERE   Apple.r_date = Pear.curr_r_date
    AND     Orange.c_id = Banana.c_id
    AND     Banana.c_id = Grape.c_id
    AND     Orange.rr_id = Apple.rr_id

(Sorry that I can't disclose all the source code but just scrambled the tables name, as the code is not written by me.)

A:

It's an indexed view that is being maintained. This is completely normal.
The reason for the maintenance is that one of the base tables of that view has been modified. Since one base table row can correspond to an arbitrary amount of view rows there can be an explosion of write activity.
You will find indexed view maintenance in the execution plan of the DML carried out on the base table.
Indexed views trade off DML speed, storage space and buffer pool occupation for improved query speed. You decide whether that is a good trade-off for you or not.

The screenshot shows one row modified in the base table (line 2). This causes big amounts of delete/insert pairs in the view. This likely is because the modified values in the base table cause rows to move in the indexes on the view to a different place.

