SAP CDS Views vs. View Entities: A Deep Dive for Modern ABAP Developers

The Evolution of Data Modeling in ABAP: CDS Views vs. View Entities

If you're an ABAP developer working on S/4HANA, you've undoubtedly worked with Core Data Services (CDS). They are the cornerstone of the modern ABAP programming model, enabling a code-pushdown strategy that significantly boosts performance. For years, the classic DDL-based CDS View was the standard. However, SAP has introduced a more powerful and streamlined successor: the CDS View Entity. This post will break down the differences, pros, and cons, and help you decide which to use in real-world scenarios.

What are Classic CDS Views (DDL-based)?

The classic CDS View, often just called a "CDS View," has been around since the early days of HANA. It's defined using the DEFINE VIEW statement. Its most defining characteristic is that upon activation, it generates two objects: the CDS entity itself and a classic SQL View in the ABAP Dictionary (SE11). This backward compatibility was crucial for its initial adoption.

Classic CDS View: Code Example

@AbapCatalog.sqlViewName: 'ZSQL_CLASSICFLIGHT'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Classic CDS View for Flights'

DEFINE VIEW Z_Classic_Flight AS SELECT FROM sflight {
  key carrid    as CarrierId,
  key connid    as ConnectionId,
  key fldate    as FlightDate,
      price     as Price,
      currency  as Currency,
      planetype as PlaneType
}

Notice the mandatory @AbapCatalog.sqlViewName annotation. This defines the name of the SE11 SQL view that will be generated.

Enter the Future: CDS View Entities

Introduced with ABAP Platform 2020, the CDS View Entity is the strategic direction for data modeling in ABAP. It's defined using the DEFINE VIEW ENTITY statement. The biggest change? It does not generate a corresponding SQL View in the ABAP Dictionary. It is a more native, streamlined object that lives entirely within the CDS world. This leads to a stricter, more consistent syntax and better performance.

CDS View Entity: Code Example

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'View Entity for Flights'

DEFINE VIEW ENTITY Z_E_Flight AS SELECT FROM sflight {
  key carrid    as CarrierId,
  key connid    as ConnectionId,
  key fldate    as FlightDate,
      price     as Price,
      currency  as Currency,
      planetype as PlaneType
}

See how clean that is? No @AbapCatalog.sqlViewName is needed because no SQL view is created. The syntax is more declarative and focused.

Key Differences at a Glance

• Syntax: DEFINE VIEW vs. DEFINE VIEW ENTITY.
• Generated Artifact: Classic views create a physical SQL view in SE11. View Entities do not.
• Client Handling: Classic views are client-dependent by default (you must specify CLIENT SPECIFIED). View Entities are client-independent by default and handle client data automatically.
• Syntax Strictness: View Entities have a much stricter syntax. For example, aliases for fields are mandatory, and joins must use the fully qualified field name (e.g., Flight.connid). This catches errors early.
• Annotations: The @AbapCatalog.sqlViewName is forbidden in View Entities.
• Performance: View Entities generally offer better performance due to the removal of the extra SQL view layer and other optimizations.

Pros and Cons: The Ultimate Showdown

Classic CDS Views

• Pros:
  • Backward Compatibility: They can be consumed by older tools or technologies that rely on SE11 dictionary views.
  • Available on Older Systems: They are your only option if you are on an S/4HANA version before ABAP Platform 2020.
• Cons:
  • Performance Overhead: The extra layer of the generated SQL view can introduce a slight performance hit.
  • Less Strict Syntax: Can lead to ambiguous or less robust code.
  • Client Handling Complexity: Requires manual client handling, which can be error-prone.

CDS View Entities

• Pros:
  • Superior Performance: A more direct and optimized path from CDS to the database.
  • Stricter & Cleaner Syntax: Enforces best practices, reduces errors, and improves code readability.
  • Future-Proof: This is SAP's recommended and strategic approach for all new developments.
  • Simplified Model: No redundant dictionary objects to manage.
• Cons:
  • Limited Backward Compatibility: Not available in older system versions.
  • Tooling Dependency: Cannot be used by legacy tools that require a physical SE11 view.

Real-World Scenarios: Making the Right Choice

So, which one should you use for your project? Here's a simple guide.

Scenario 1: You are starting a new greenfield S/4HANA project on a recent version (2020 or later).

Recommendation: Use CDS View Entities exclusively for all new data models. This is a no-brainer. You get the best performance, maintainability, and alignment with SAP's future roadmap. You are building on the most modern foundation available.

Scenario 2: You need to expose data to a legacy external tool (like a non-SAP BI tool) that can only connect to the ABAP Dictionary via RFC and read SE11 views.

Recommendation: Use a Classic CDS View. Because View Entities don't create an SE11 artifact, the legacy tool wouldn't be able to find or consume the data. The Classic View's generated SQL view is essential for this integration scenario.

Scenario 3: You are extending a standard SAP Fiori app that is built entirely on Classic CDS Views.

Recommendation: It's often best to stick with Classic CDS Views for consistency within that specific development. While you *can* build a View Entity on top of a Classic View, maintaining a consistent technology stack within a single application or extension can simplify maintenance and troubleshooting for the entire team.

Conclusion: Embrace the Future, but Respect the Past

The message from SAP is clear: CDS View Entities are the future of data modeling in ABAP. For any new development on a supported S/4HANA platform, they should be your default choice. They offer a cleaner, faster, and more robust alternative to their classic predecessors. However, Classic CDS Views still have their place, particularly for ensuring backward compatibility with older systems and tools. Understanding the strengths and weaknesses of both allows you, the developer, to make the smartest architectural decision for every situation you encounter.