Abstract: Techniques are described herein that are capable of translating programming language patterns into database schema patterns. Examples of a programming language pattern include but are not limited to a source code pattern, an intermediate language code pattern, metadata associated with a source code pattern, metadata associated with an intermediate language code pattern, or any combination thereof. The programming language patterns may define objects that are included in an object model. Database schema patterns that define a database are automatically (e.g., inferentially) created based on respective programming language patterns that define objects of an object model. The programming language patterns are automatically mapped to the respective database schema patterns.

Abstract: Techniques are described herein that are capable of translating programming language patterns into database schema patterns. Examples of a programming language pattern include but are not limited to a source code pattern, an intermediate language code pattern, metadata associated with a source code pattern, metadata associated with an intermediate language code pattern, or any combination thereof. The programming language patterns may define objects that are included in an object model. Database schema patterns that define a database are automatically (e.g., inferentially) created based on respective programming language patterns that define objects of an object model. The programming language patterns are automatically mapped to the respective database schema patterns.

Abstract: Techniques are described herein that are capable of translating programming language patterns into database schema patterns. Examples of a programming language pattern include but are not limited to a source code pattern, an intermediate language code pattern, metadata associated with a source code pattern, metadata associated with an intermediate language code pattern, or any combination thereof. The programming language patterns may define objects that are included in an object model. Database schema patterns that define a database are automatically (e.g., inferentially) created based on respective programming language patterns that define objects of an object model. The programming language patterns are automatically mapped to the respective database schema patterns.

Abstract: Techniques are described herein that are capable of translating programming language patterns into database schema patterns. Examples of a programming language pattern include but are not limited to a source code pattern, an intermediate language code pattern, metadata associated with a source code pattern, metadata associated with an intermediate language code pattern, or any combination thereof. The programming language patterns may define objects that are included in an object model. Database schema patterns that define a database are automatically (e.g., inferentially) created based on respective programming language patterns that define objects of an object model. The programming language patterns are automatically mapped to the respective database schema patterns.

Abstract: A balance is provided between automation of repetitive database creation and configuration efforts, on the one hand, and flexibility to depart from prior configurations, on the other hand, to assist developers with aspects of database initialization. An application domain includes data context instances, database connections, object models mapped by an object-relational mapper, and database initializers. Upon the first attempted runtime use of a particular database connection—data context instance—object model combination, a database initializer is invoked. Initializers may check to see if the database exists, (re)generate a database and schema based on the object model, determine whether the database is compatible with the current object model, delete the database and its schema, seed data, modify database indexes, and/or migrate an existing database, for example. A custom initializer can run developer-supplied code as desired to place the database in a known state for use by the application.

Abstract: Fluent API Patterns promote balance in managing object persistence. Code which obtains an object-relational mapper session contains API Patterns that manipulate persistence ignorant objects using calls to a fluent interface. When the developer's code executes, it may manipulate an object state, a property state, and/or a persistent relationship of the persistence ignorant object. The code may implement API Patterns such as find-change-save, current-value-original-value, nested-property, incremental-graph-load, incremental-graph-filtered-load, property-modification, dictionary, and/or other API Patterns. Additional examples of API Patterns include an API Pattern to read current, original, and database values for all properties of an entity; an API Pattern to set current and/or original values from another object; and an API Pattern to create a cloned object containing current, original, and/or database values.

Abstract: Aspects of the subject matter described herein relate to mapping from application objects to an abstract data model. In aspects, a mapper receives registrations that indicate behavior (e.g., how objects are constructed, modified, or examined) of application objects. The behavior may be specified using user-supplied expressions. The mapper aggregates this data and uses it to map application requests for data access into one or more operations that operate on the abstract data model. A data access layer may then translate the operations into actions to access data corresponding to the requests from a store. If appropriate, data obtained from the store may then be inserted into application objects as indicated by the registrations.

Abstract: Techniques are described herein that are capable of translating programming language patterns into database schema patterns. Examples of a programming language pattern include but are not limited to a source code pattern, an intermediate language code pattern, metadata associated with a source code pattern, metadata associated with an intermediate language code pattern, or any combination thereof. The programming language patterns may define objects that are included in an object model. Database schema patterns that define a database are automatically (e.g., inferentially) created based on respective programming language patterns that define objects of an object model. The programming language patterns are automatically mapped to the respective database schema patterns.

Abstract: Fluent API Patterns promote balance in managing object persistence. Code which obtains an object-relational mapper session contains API Patterns that manipulate persistence ignorant objects using calls to a fluent interface. When the developer's code executes, it may manipulate an object state, a property state, and/or a persistent relationship of the persistence ignorant object. The code may implement API Patterns such as find-change-save, current-value-original-value, nested-property, incremental-graph-load, incremental-graph-filtered-load, property-modification, dictionary, and/or other API Patterns. Additional examples of API Patterns include an API Pattern to read current, original, and database values for all properties of an entity; an API Pattern to set current and/or original values from another object; and an API Pattern to create a cloned object containing current, original, and/or database values.

Abstract: A balance is provided between automation of repetitive database creation and configuration efforts, on the one hand, and flexibility to depart from prior configurations, on the other hand, to assist developers with aspects of database initialization. An application domain includes data context instances, database connections, object models mapped by an object-relational mapper, and database initializers. Upon the first attempted runtime use of a particular database connection—data context instance—object model combination, a database initializer is invoked. Initializers may check to see if the database exists, (re)generate a database and schema based on the object model, determine whether the database is compatible with the current object model, delete the database and its schema, seed data, modify database indexes, and/or migrate an existing database, for example. A custom initializer can run developer-supplied code as desired to place the database in a known state for use by the application.

Abstract: Aspects of the subject matter described herein relate to mapping from application objects to an abstract data model. In aspects, a mapper receives registrations that indicate behavior (e.g., how objects are constructed, modified, or examined) of application objects. The behavior may be specified using user-supplied expressions. The mapper aggregates this data and uses it to map application requests for data access into one or more operations that operate on the abstract data model. A data access layer may then translate the operations into actions to access data corresponding to the requests from a store. If appropriate, data obtained from the store may then be inserted into application objects as indicated by the registrations.

Abstract: Aspects of the subject matter described herein relate to mapping from application objects to an abstract data model. In aspects, a mapper receives registrations that indicate behavior (e.g., how objects are constructed, modified, or examined) of application objects. The behavior may be specified using user-supplied expressions. The mapper aggregates this data and uses it to map application requests for data access into one or more operations that operate on the abstract data model. A data access layer may then translate the operations into actions to access data corresponding to the requests from a store. If appropriate, data obtained from the store may then be inserted into application objects as indicated by the registrations.

Abstract: Aspects of the subject matter described herein relate to mapping from application objects to an abstract data model. In aspects, a mapper receives registrations that indicate behavior (e.g., how objects are constructed, modified, or examined) of application objects. The behavior may be specified using user-supplied expressions. The mapper aggregates this data and uses it to map application requests for data access into one or more operations that operate on the abstract data model. A data access layer may then translate the operations into actions to access data corresponding to the requests from a store. If appropriate, data obtained from the store may then be inserted into application objects as indicated by the registrations.