Creating an object view

Question

Is it possible to create a representation of an object in essence without creating a representation in the DAL?

I have a parent table named Receipt. The receipt may be active or inactive. if I implement IsActive as a receipt attribute, there is a high risk of forgetting to attach .Where(r=>r.IsActive) to all Linq queries and the high cost of adding it to previous codes. I tried to inherit the DeletedReceipt child with the condition IsActive = false in the model and add the condition IsActive = true to Receipt (Parent). Fortunately, business has not changed the situation. the problem is that I cannot write a deactivation method, while the receipt has many important relationships. and I know that this is not object oriented. I think I can handle it. but I do not change my DAL for the business method! the case "IsActive" plays the role of the discriminator and cannot be updated in the deactivation method. one way might be to use SP, but that means "DAL, please handle my damn business logic." any idea?

Answer 1

There are two ways to create a view:

• DefiningQuery - Custom SQL selection in the SSDL part of the EDMX file. You can use any SQL to define a new read-only object. The problem is that after use, you will no longer be able to use the update from the database, as it will overwrite your changes in EDMX (unless you buy a more powerful extension for the EF designer).
• QueryView - custom ESQL selects the EDMX file in the MSL part, which must be selected from existing objects. It maintains relationships, but only for other types of queries.

In both cases, the created entity is view = read-only. You cannot use it to save changes if you do not correlate the update, insert, and delete operations with a stored procedure or custom SQL (written to the EDMX file again).

In any case, what you are trying to do will lead to many problems. Have you ever had to DeletedReceipt in your application? If yes, then you need to have full logic, as you have with ActiveReceipt ? If not, do not do this.

The problem is that the IsActive condition for soft deletion is that EF does not handle well. You can solve the problem for your main query, where you do not need to use Where(r => r.IsActive) , but do you always use boot loading or lazy loading to load related receipts for any other objects? If so, do you expect to download only active receipts? This is where the real problem arises. No filtering of the download with impatience or lazy loading is required, so you will always download both active and deleted records. The only way to handle this (without doing everything manually) is conditional matching , but conditional matching allows you to have only one of these objects in your application and you need a special stored procedure for soft deletion.

"DAL, please handle my damn business logic."

As a side note to this quote, if you do not want DAL to process any logic, do not expect it to give you only active receipts automatically. This is the logic in DAL. Therefore, if you really mean that using Where(r => r.IsActive) in all queries is what you are looking for. If you want some help from the DAL, it should contain some logic, and sometimes the logic will be in SQL.