Tài liệu hướng dẫn ứng dụng ADO.NET Entity Framework vào thiết kế phần mềm theo DDD (Domain Driven Design)

1. Master thesis in Software Engineering and Management
REPORT NO. 2008:016
ISSN: 1651-4769
Department of Applied Information Technology
Using ADO.NET Entity Framework in Domain-Driven
Design: A Pattern Approach
ANDREY YEMELYANOV
IT University of Göteborg
Chalmers University of Technology and University of Gothenburg
Göteborg, Sweden 2008

2. Using ADO.NET Entity Framework in Domain-Driven Design: A Pattern Approach
ANDREY YEMELYANOV
© ANDREY YEMELYANOV, 2008
Report no. 2008:016
ISSN: 1651-4769
Department of Applied Information Technology
IT University of Göteborg
Chalmers University of Technology and University of Gothenburg
P O Box 8718
SE – 402 75 Göteborg
Sweden
Telephone +46 (0) 31-772 4895
I

3. Using ADO.NET Entity Framework in Domain-Driven Design: A Pattern Approach
ANDREY YEMELYANOV
Department of Applied Information Technology
IT University of Göteborg
Chalmers University of Technology and University of Gothenburg
Supervisor: Miroslaw Staron
ABSTRACT
In the object community domain-driven design philosophy has recently gained prominence. The
application of domain-driven design practices in iterative software development projects promises to
conquer complexity inherent in building software. And with the reduced complexity comes more
intimate understanding of a problem domain, which results in better software, capable of effectively
addressing user needs and concerns. The ADO.NET Entity Framework with its emphasis on modeling
conceptual business entities and handling persistence can potentially facilitate domain-driven design.
However, it is not clear exactly how the framework should be used in the context of domain-driven
development. This exploratory case study was commissioned by Volvo Information Technology (Volvo
IT) and it sought to provide guidance on using the Entity Framework in domain-driven design at the
company. The study produced a number of important results. Firstly, a total of 15 guidelines were
proposed for adopting the framework at Volvo IT. These guidelines address such issues as domain
modeling during requirements engineering, efficient mapping among various models, reverse-
engineering of legacy databases, and a number of others. Secondly, six critical factors (performance,
abstraction, competence, features, simplicity and support for multiple data sources) were identified that
must be considered in adopting the Entity Framework in domain-driven design at the company. Finally,
based on one of these factors, performance evaluation of the framework’s querying mechanisms was
performed, which further strengthened the guidelines.
Keywords
Domain-driven design, ADO.NET Entity Framework, persistence, domain model, patterns, object-
relational impedance mismatch.
II

4. ACKNOWLEDGEMENTS
This Master thesis has been a great exercise in knowledge discovery which would have been impossible
without:
The Swedish Institute, whose kind support in cultural and monetary aspects has kept me going
throughout my whole stay in Sweden. I would like to thank the Swedish Institute for granting me a
scholarship to pursue my studies at the IT University.
Miroslaw Staron – Software Engineering and Management program manager at the IT University, who
was an academic supervisor of mine. Miroslaw provided valuable guidance on tackling the study most
effectively. I would like to thank him for his patience, understanding and, most importantly, objective
criticism of my work.
Ludwik Wallin – an architect at Volvo Information Technology, who was an industrial supervisor of
mine. Ludwik provided a valuable insight into the issues concerning building enterprise software and
also guided me towards relevant aspects of the Entity Framework and domain-driven design that need be
carefully studied. I would also like to thank all the employees from the Software Process Improvement
group and other departments at Volvo IT who contributed to this study with important interviews and
informal discussions.
Thanks again to all of you for your help, time and willingness to share experience and insightful
comments!
Andrey Yemelyanov
May 17, 2008
Gothenburg, Sweden.
III

5. TABLE OF CONTENTS
1. INTRODUCTION................................................................................................................. 1
2. CASE STUDY DESIGN ....................................................................................................... 3
2.1 Context and Subjects ...................................................................................................... 3
2.2 Study Subjects................................................................................................................. 3
2.3 Data Collection and Analysis.......................................................................................... 3
2.4 Study Execution .............................................................................................................. 3
2.5 Threats to Validity .......................................................................................................... 4
3. RELATED WORK ............................................................................................................... 4
4. THEORETICAL FRAMEWORK ...................................................................................... 5
4.1 Structuring domain logic................................................................................................. 5
4.1.1 Procedural style (Transaction Script)..................................................................... 6
4.1.2 Domain Model style ................................................................................................ 7
4.2 Domain-driven design..................................................................................................... 7
4.2.1 The building blocks of domain-driven design......................................................... 8
4.2.1.1 Layered architecture............................................................................................ 8
4.2.1.2 Entities ................................................................................................................ 8
4.2.1.3 Services ............................................................................................................... 8
4.2.1.4 Aggregates .......................................................................................................... 9
4.2.1.5 Factories.............................................................................................................. 9
4.2.1.6 Repository ........................................................................................................... 9
4.3 The ADO.NET Entity Framework.................................................................................. 9
4.3.1 The building blocks of the Entity Framework......................................................... 9
4.3.1.1 The Entity Data Model...................................................................................... 10
4.3.1.2 Entity client ....................................................................................................... 10
4.3.1.3 Entity SQL ........................................................................................................ 10
4.3.1.4 Object Services ................................................................................................. 10
4.3.1.5 LINQ to Entities................................................................................................ 10
4.3.2 Accessing data via the Entity Framework and SQL Client................................... 11
4.3.3 Concluding remarks.............................................................................................. 12
5. ADOPTING THE ENTITY FRAMEWORK
IN DOMAIN-DRIVEN DESIGN: MAIN REQUIREMENTS .............................................. 12
5.1 Main goals..................................................................................................................... 12
5.2 Main requirements ........................................................................................................ 13
IV

6. 5.3 The role of the guidelines requirements........................................................................ 13
6. ENTITY FRAMEWORK IN DOMAIN-DRIVEN
DESIGN: CRUCIAL FACTORS .............................................................................................. 13
6.1 Interviews...................................................................................................................... 13
6.2 Factors........................................................................................................................... 13
6.3 Data retrieval performance............................................................................................ 14
6.4 Support for higher-level abstractions............................................................................ 14
6.5 In-house competence level in objects, databases and object-relational mismatch........ 15
6.6 Rich feature set ............................................................................................................. 15
6.7 Simplicity...................................................................................................................... 15
6.8 Support for heterogeneous data sources for the domain model .................................... 15
6.9 Concluding remarks ...................................................................................................... 15
7. QUERY PERFORMANCE EVALUATION.................................................................... 16
7.1 SqlDataReader .............................................................................................................. 17
7.2 NHibernate .................................................................................................................... 17
7.3 Entity Framework ......................................................................................................... 17
7.3.1 Entity SQL............................................................................................................. 18
7.3.2 LINQ to Entities .................................................................................................... 18
7.3.3 Compiled LINQ to Entities ................................................................................... 18
7.4 Analysis......................................................................................................................... 18
8. ENTITY FRAMEWORK GUIDELINES………………………………………………..19
8.1 Pattern discovery process.............................................................................................. 20
8.2 Core guidelines ............................................................................................................. 20
8.2.1 Guideline 1: Business domain modeling............................................................... 20
8.2.2 Guideline 2: Capturing domain logic ................................................................... 20
8.2.3 Guideline 3: Expressing domain model in software ............................................. 20
8.2.4 Guideline 4: Validating the domain model........................................................... 21
8.2.5 Guideline 5: Applying the Aggregate pattern....................................................... 21
8.2.6 Guideline 6: Applying the Repository pattern ...................................................... 21
8.2.7 Guideline 7: Reverse engineering......................................................................... 21
8.2.8 Guideline 8: Implementing business rules in the Entity Framework.................... 21
8.3 Mapping patterns………………………………………………………………………21
8.3.1 Pattern: Object Association.................................................................................. 21
8.3.2 Pattern: Object Aggregation................................................................................. 21
8.3.3 Pattern: Object Composition ................................................................................ 21
V

7. 8.3.4 Pattern: Object Self-Association........................................................................... 21
8.3.5 Pattern: Object Inheritance .................................................................................. 22
8.3.6 Pattern: Domain Object........................................................................................ 22
8.3.7 Pattern: Advanced Mapper................................................................................... 22
8.3.8 Mapping pattern example ..................................................................................... 23
9. DISCUSSION ...................................................................................................................... 23
9.1 Why patterns? ............................................................................................................... 23
9.2 Initial evaluation ........................................................................................................... 23
10. CONCLUSION ................................................................................................................... 24
10.1 Key findings.................................................................................................................. 24
10.2 Future research.............................................................................................................. 24
11. ACKNOWLEDGMENTS .................................................................................................. 25
12. REFERENCES.................................................................................................................... 25
LIST OF FIGURES
Figure 1: Part of a banking application built in a procedural style………………………………...6
Figure 2: Transitioning from procedural database-driven
design to domain-driven design……………………………………………………………………7
Figure 3: A navigation map of the language of domain-driven design.............................................8
Figure 4: Layered architecture according to DDD…………………………………………………8
Figure 5: Aggregate…………………………………………...........................................................9
Figure 6: Entity Framework architecture………………………………………………………….10
Figure 7: Order application relational schema…………………………………………………….11
Figure 8: Data access with the SQL Client..………………………………………………………11
Figure 9: Conceptual Entity Data Model built
on top of the relational database schema in the order application..……………………………….12
Figure 10: Data access with LINQ in the Entity Framework...……………………………………12
Figure 11: Domain aggregate retrieved from the relational database……………………………..16
Figure 12: Relational model underlying the Blog Aggregate……………………………………..16
Figure 13: SQL query to retrieve the Blog aggregate………… …………………… …………..16
Figure 14: SQL Client............................................................... .....................................................17
Figure 15: hSQL in NHibernate……………………………… …………………………… …..17
Figure 16: The Entity Data Model generated from the Blog relational model……………………18
Figure 17: Compiled LINQ to Entities query…………………………………………………......18
VI

8. Figure 18: A comparative evaluation of query performance
with DataReader, NHibernate and the Entity Framework……………………………………....19
Figure 19: Taxonomy of the Entity Framework Guidelines………………………………….....20
Figure 20: Object association……………………………………………………………………21
Figure 21: Object aggregation…………………………………………………………………...21
Figure 22: Object composition…………………………………………………………………..21
Figure 23: Object self-association……………………………………………………………….22
Figure 24: Table-Per-Hierarchy inheritance mapping…………………………………………...22
Figure 25: Table-Per-Concrete-Class inheritance mapping…………………………………......22
Figure 26: Table-Per-Class inheritance mapping………………………………………………..22
Figure 27: Multiple association………………………………………………………………….22
Figure 28: Mapping to relational model…………………………………………………………22
LIST OF APPENDICES
Appendix A: Interview questions..................................................................................................27
Appendix B: C# code to retrieve the Blog aggregate with the SQL client…....…………………29
Appendix C: Example domain model based on domain-driven design principles.......................31
VII

9. Using ADO.NET Entity Framework in Domain-Driven
Design: A Pattern Approach
Andrey Yemelyanov
IT University of Göteborg
yemelyan@ituniv.se
ABSTRACT
In the object community domain-driven design philosophy has hand, specifies how the given problem is to be solved. Crain [19]
recently gained prominence. The application of domain-driven refers to this model as a platform-specific model because it
design practices in iterative software development projects captures “a mixture of behavior and technology”. For example,
promises to conquer complexity inherent in building software. the design model may include a JDBC 1class to specify how the
And with the reduced complexity comes more intimate lifecycle of persistent business objects is handled.
understanding of a problem domain, which results in better Such a seeming redundancy in models is necessary in order to
software, capable of effectively addressing user needs and ensure a smooth transition from a problem space (use case
concerns. The ADO.NET Entity Framework with its emphasis on specifications and analysis model) to a solution space (design and
modeling conceptual business entities and handling persistence implementation models), which is not trivial. Evans [22] argues
can potentially facilitate domain-driven design. However, it is not that once the implementation begins, analysis and design models
clear exactly how the framework should be used in the context of grow increasingly disjoint. This happens because the analysis
domain-driven development. This exploratory case study was model is created with no design issues in mind. Mixing
commissioned by Volvo Information Technology (Volvo IT) and implementation concerns into analysis models is considered bad
it sought to provide guidance on using the Entity Framework in practice and is, therefore, highly discouraged. As a result, the pure
domain-driven design at the company. The study produced a analysis model proves impractical for design purposes and is
number of important results. Firstly, a total of 15 guidelines were abandoned as soon as programming begins [22]. There is a danger
proposed for adopting the framework at Volvo IT. These to such practice, Evans [22] continues. While analysis models
guidelines address such issues as domain modeling during may accurately capture business needs and incorporate valuable
requirements engineering, efficient mapping among various knowledge about the problem domain, there is no guarantee that
models, reverse-engineering of legacy databases, and a number of the design model will successfully rediscover the insights gained
others. Secondly, six critical factors (performance, abstraction, during analysis. Eventually, as the gap between the models
competence, features, simplicity and support for multiple data widens, it becomes progressively difficult to feed insights from
sources) were identified that must be considered in adopting the analysis into design.
Entity Framework in domain-driven design at the company.
Finally, based on one of these factors, performance evaluation of Domain-driven design (DDD) [22] vision seeks to bridge the
the framework’s querying mechanisms was performed, which chasm between analysis and design by introducing a single model
further strengthened the guidelines. (domain model) that addresses both concerns. A domain model
not only represents an important analysis artifact that captures
essential business concepts and constraints but also offers a
Keywords concrete design in the form of object-oriented design classes.
Domain-driven design, ADO.NET Entity Framework, persistence, Constituting an essential part of application design and
domain model, patterns, object-relational impedance mismatch. architecture, domain models in DDD are expressed in terms of
object-oriented constructs such as classes, attributes, operations
1. INTRODUCTION and relationships and are drawn with the UML class diagram
In a use-case driven software development process [3, 8, 14, 39] notation (see for example [22, 31] and Appendix C). These
use cases serve as a primary artifact for establishing system models may be referred to as domain object models or conceptual
requirements, validating system architecture, testing and models [25, 31]. We will henceforth refer to such models as just
communicating with domain experts and other project domain models2. The basic premise behind DDD is the
stakeholders [13]. Such a process is often used alongside with the maximization of knowledge about the domain. This is achieved by
Unified Modeling Language (UML) [8]. After the use case a close cooperation between a project team and domain experts
specification is fed into further development stages, two major with the goal of creating an explicit model of the problem domain.
artifacts are conceived: analysis model and design model. There is As a result, it is possible to reduce complexity inherent in most
an interesting dichotomy between the two models in that they
address two distinct dimensions (problem and solution) of the
same given domain. The analysis model represents the product of
1
analyzing a problem domain to organize its concepts. What role Java Database Connectivity (JDBC) is a technology for connecting to
these concepts will play in software is not important in that relational databases from Java applications.
2
context [22]. It specifies what problem needs to be solved. The Note that in this thesis we address domain-driven design in the context
major content of the analysis model includes collaborations in the of business information systems. We do not consider DDD as applied in
UML and analysis classes [19]. The design model, on the other embedded systems design or any other domain.
1

10. businesses. This, in turn, should lead to better software that should occur, how models can be validated with the EF, or how
effectively supports business operations. DDD with the EF will affect requirements engineering stage.
These, we believe, are important issues that must be considered.
There is a challenge in using domain models in applications. On
the one hand, to effectively model a complex business domain 1.2 Thesis objective
with all its valuable operation logic, domain models would This exploratory study was commissioned by Volvo Information
necessarily have to use a number of object-oriented constructs, Technology (Volvo IT) – a subsidiary of the Volvo Corporation
such as inheritance, aggregation/composition and design patterns. based in Gothenburg, Sweden. The impetus for Volvo IT to move
These are so-called ‘rich’ or ‘deep’ domain models [22, 25]. On toward DDD practices with the EF is the potential reduction in
the other hand, to provide persistent storage of the domain model code complexity and further improvement of maintainability of its
state, relational databases are widely used. The fact that these enterprise applications. Accordingly, the objective of this study is
databases use a relational data model to organize data places a to formulate guidance on applying the Entity Framework in DDD
practical limit on the ‘richness’ of domain models [25]. This is in the context of an iterative software development process at
caused by a paradigm difference between object-oriented and Volvo IT. It addresses the following main research question:
relational models, which in literature is referred to as object-
relational impedance mismatch [7, 16, 18, 33, 38]. The basic How should software development projects that emphasize
premise behind it is that objects and relations are fundamentally domain-driven design incorporate the Entity Framework for
different and their interplay is not trivial [38]. Fowler [25] domain modeling and domain object persistence?
discusses structural and behavioral aspects of the impedance
The main research question can be broken down into the
mismatch. In a structural sense, the author identifies two major
following sub-questions:
distinctions between objects and relations: identity and
relationships handling. From the behavioral perspective, a RQ1: What are the main goals behind the company’s move to
problem arises when it comes to maintaining data in objects and further develop domain-driven design practices with the Entity
their corresponding database tables in a consistent state. Issues Framework?
that need to be considered, for example, are loading objects,
ensuring no object for the same row is read more than once and RQ2: What are the most important factors that must be taken into
handling database updates. Due to impedance mismatch efficient account when adopting the Entity Framework in domain-driven
mapping of ‘rich’ domain models to relational models presents a design in the company?
problem. RQ3: What are the most important guidelines for adopting the
Entity Framework in domain-driven software development in the
1.1 Problem definition company?
While Evans [22] stresses that DDD is a set of principles focusing
on modeling a business domain and needs no technological and The thesis achieved a number of important results. Firstly, a set of
methodological support other than object orientation, we believe 15 guidelines were proposed for adopting the EF at Volvo IT.
that effective adoption of DDD practices is contingent on the These guidelines address such issues as domain modeling during
availability of tools. Essentially, such a tool would need to requirements engineering, efficient mapping between domain
directly support domain modeling activity and offer concrete models and the EDM, reverse-engineering of legacy databases,
solutions to overcoming object-relational mismatch. In the late and a number of others. Secondly, a number of critical factors
2007, Microsoft Corporation announced the Beta 3 release of the were identified that must be considered in using the EF with
ADO.NET Entity Framework (further abbreviated to EF or just DDD. Based on one of these factors, performance evaluation of
referred to as Entity Framework) [34]. The EF is .NET-based EF querying mechanisms was performed, which further
middleware that represents an abstraction layer that promises to strengthened the guidelines.
alleviate impedance mismatch by decoupling application domain
models from underlying relational storage models. A 1.3 Disposition
distinguishing characteristic of the EF is the built-in support for The remainder of the report is structured as follows. Section 2
development based on an explicit model. It introduces the Entity discusses the research methodology used in the study. Section 3
Data Model (EDM), which captures essential business (domain) presents a brief overview of the related work. Section 4 delves
entities and their relationships in an explicit conceptual model. into the theoretical framework which served as the knowledge
foundation for the study. Section 5 addresses RQ1 by presenting
The EF can potentially facilitate DDD as it not only largely main goals of moving to DDD practices with the Entity
overcomes object-relational mismatch but also promotes model- Framework at Volvo IT. This section also discusses important
based development of business applications. The resulting requirements that the guidelines have to fulfill. Section 6
adoption of DDD in software development promises to raise the addresses RQ2 and presents critical factors that must be taken into
quality of delivered software. However, it is not clear how the consideration when adopting the Entity Framework for DDD at
feature set offered by the EF can support the DDD practices. To Volvo IT. Section 7 builds upon the preceding section and
our best knowledge, no guidance has been published on how the presents the evaluation of the most important factor– query
EF should be effectively integrated into a software development performance. Section 8 presents the overview of the Entity
process with a particular emphasis on DDD. To date, one credible Framework Guidelines (RQ3). Section 9 offers some further
source on the EF is the documentation released by Microsoft [35]. reflections on the guidelines. Finally, Section 10 ends the report
However, it is limited to programming scenarios and by presenting important conclusions and outlining recommended
walkthroughs. There exists no formal advice on mapping between future research.
models should be performed, how and when domain modeling
2

11. 2. CASE STUDY DESIGN confidentiality agreement with Volvo IT, the guidelines developed
The main purpose of this study was to design a set of guidelines in the thesis are a proprietary asset of the company and, therefore,
for incorporating the EF into a domain-driven software only their outline will be presented in this report.
development process at Volvo IT. We used a qualitative 2.2 Study Subjects
exploratory case study as the methodology behind the study The subjects in the case study were 1 senior .NET architect, 3
design [48]. Exploratory case studies are suitable for performing software architects and 2 system analysts. The senior .NET
preliminary studies where it is not clear which phenomena are architect provided much-needed guidance on identifying real
significant to look into, or how to quantitatively assess these industrial problems with regards to domain-driven development
phenomena [21]. Moreover, to our best knowledge, research and object-relational mismatch. He outlined important
concerning the adoption of Entity Framework in domain-driven benchmarks and requirements that the guidelines had to satisfy.
development is non-existent and current literature provides no The rationale for selecting other software architects as primary
conceptual framework for theorizing. This circumstance makes subjects was their first-hand exposure to object modeling and
the formulation of a proper hypothesis or theory prior to persistence. These architects provided critical data that allowed us
commencing the study difficult. Another justifiable rationale for to identify common object modeling and persistence mechanisms,
choosing an exploratory case study is the descriptive nature of their characteristics, and also factors affecting the adoption of
research questions. Rather than asking to provide causative links Entity Framework at Volvo IT. In involving system analysts in the
(why?), research objectives in this study mainly focus on so-called study we sought to identify common methods and techniques used
what?-questions where the major goal is to develop hypotheses for requirements modeling in the company. In this way, we could
for further scientific inquiry. see whether system analysis (in which domain modeling should
The research paradigm of this case study can be characterized as play an important part) placed any limitations on using pure
interpretive. Unlike positivist approach where reality can be domain-driven design approaches in building business
objectively described with measurable properties, interpretive applications.
paradigm seeks to gain knowledge through less precise
constructions such as language and shared meanings [9, 41]. It is
2.3 Data Collection and Analysis
To increase overall reliability of the study a method of data
particularly applicable in cases where a degree of uncertainty
triangulation was used. That is, a number of data collection
surrounds the problem (i.e. very little prior research exists).
methods were used to collect evidence. The primary method for
Essentially, we tried to understand the phenomena of domain
data collection was interviewing. Five semi-structured interviews
modeling and object persistence at Volvo IT through the
were conducted with software architects and system analysts to
meanings that people assign to them. The aim was to interpret
gain knowledge about object persistence approaches and domain
how software architects and system analysts understand domain
modeling in general. Each interview lasted about one hour. Due to
driven design and object persistence, what they view as best
time limitations, interview questions tended to be very focused
practices and why. This was achieved through a series of semi-
and concrete (see Appendix A). Still, an interviewee was allowed
structured interviews (see later in the section). Our interpretations
maximum reasonable latitude in elaborating. Interview questions
were then used in formulating the Entity Framework guidelines,
were refined after each interview to account for new information.
which can be understood as the tentative theory behind applying
Each interview was recorded. Subsequently, all interviews were
the EF in DDD. The guidelines represent an initial theory – a
transcribed and the transcripts were analyzed on the subject of any
theory that must be tested repeatedly to be corroborated or
recurring words or phrases. The transcripts were explicitly
disproved.
analyzed according to expected outcomes of the thesis work. No
2.1 Context and Subjects statistical analysis was performed on data extracted from
The studied company in this research project was Volvo interviews.
Information Technology (referred to as Volvo IT henceforth). The In addition to interviews, extensive body of software
company is a wholly-owned subsidiary of AB Volvo (Volvo documentation was reviewed from the software portfolio at Volvo
Group), one of the largest industrial groups in the Nordic region. IT. Important information from the documentation was noted and
Volvo IT is the information technology competence center for later revisited for analysis. This initial study made further
Volvo Group. It provides software solutions to support industrial interview questions more focused and relevant. Moreover, an
processes with competencies in Product Lifecycle Management, experiment aimed at evaluating the performance of the Entity
SAP solutions, and IT operations. This case study was Framework query execution provided important input to thesis
commissioned by Software Process Improvement (SPI) group result. Finally, a number of informal discussions with the senior
within Volvo IT, which is responsible for developing and .NET architect also complemented evidence gathered during the
maintaining processes and methods for application development. study.
The group was exploring a possibility of adopting the Entity
Framework as a persistence mechanism in software development 2.4 Study Execution
projects that emphasize domain-driven design. Accordingly, the The case study was performed on Volvo IT premises in
development of guidance on adopting the framework is a unit of Gothenburg (Sweden) during the 20-week spring semester period.
analysis (case) in this study. To our best knowledge, no previous The study was executed in the following stages:
studies have been performed in this area. Thus, the conclusions
Stage 1: Several initiation interviews were conducted with the
drawn in this case study could potentially inform critical decisions
senior .NET architect to identify main goals for transitioning to
about incorporating the framework into domain-driven
DDD with the Entity Framework at Volvo IT. The interviews also
development in a number of similar enterprises. Due to the
sought to elicit important requirements that the Entity Framework
3

12. guidelines would need to fulfill. The data collected during the multiple sources of information: interviews, documents and
interviews addressed RQ1 and served as the basis for further informal conversations. Moreover, the findings from data
guidelines verification. collection were evaluated by interviewees during a joint Entity
Framework workshop.
Stage 2: Five interviews with software architects and system
analysts were performed. The goal of these interviews was to However, the construct validity threat to this study still remains
identify the most common pattern of working with object because we cannot guarantee that during the one-hour workshop
modeling and persistence during software development at the the understandability and the readability of the guidelines could
company. Furthermore, this stage sought to elicit specific be verified with absolute certainty. During the presentation some
concerns that needed to be addressed in adopting the EF. The data of the interviewees deemed the guidelines too abstract in their
obtained from the interviews was augmented by observing one pattern form, while others considered the level of abstraction
software architect working with a persistence layer in an actual appropriate. Ultimately, we believe the most reliable way to verify
system. Besides, considerable amount of data was collected the guidelines in this regard would be to test them in a real
through studying documentation for the Entity Framework and development project. However, we did not have this opportunity.
some internal Volvo IT production systems as well as during Still, we believe we managed to curtail this threat to some extent
informal discussions with the senior .NET architect. In this way, by including concrete examples within each guideline.
not only RQ2 was addressed, but also enough information was
Another threat to construct validity relates to the fact that only the
gathered to begin creating the EF guidelines.
Beta 3 version of the ADO.NET Entity Framework was used in
Stage 3: Based on the evidence collected during stages 1 and 2 a the performance experiment (see Section 7). Thus, the results
set of guidelines for adopting Entity Framework in domain-driven from an experiment with the release-to-manufacturing version of
design were created. RQ3 was thus partially addressed. the framework could diverge from our results, which were
obtained with the Beta 3 version.
Stage 4: The purpose of this final stage was to perform initial
evaluation of the guidelines proposed in Stage 3. The objective
was the verification of understandability and readability of the 3. RELATED WORK
guidelines. This was achieved through a joint Entity Framework The primary source for domain-driven design principles is Evans
workshop where the researcher and all study subjects discussed [22]. The author introduces a number of important fundamental
the guidelines. Thus, RQ3 was completely addressed. concepts and guidelines for adopting DDD practices within a
software development project. However, he does not provide the
Eventually, by answering all three research sub-questions we were guidelines in the context of any specific tool. Fowler [25] also
able to address the main research question of the case study. offers a relevant discussion of object-oriented domain models and
2.5 Threats to Validity other alternatives to modeling domain logic. Besides, the author
presents a detailed discussion of object-relational mapping
According to Yin [48], a case study design needs to satisfy the
approaches. Nilsson [36] offers an interesting discussion of
following important quality conditions: construct validity, internal
implementing domain object models in C# programming
validity, external validity, and reliability. Due to its exploratory
language. He considers such issues as building a domain object
nature this case study’s design is not exposed to internal validity
factory, creating a repository for object aggregates and mapping
threat. That is, the current case study does not seek to identify
domain objects to relational tables with the NHibernate mapping
causal links in phenomena, which makes internal validity not a
tool.
concern.
Still, after an extensive literature review we found no studies of
To achieve sufficient reliability the case study design adhered to how the Entity Framework, based on a conceptual data model, can
the two basic principles specified by Yin [48]. First, data be incorporated into domain-driven software development. To our
triangulation was applied to minimize the risk of bias in data best knowledge, there is no research into how rich domain models
collected from a single source. Accordingly, we augmented should be mapped and persisted to a relational database via an
interview data with data from software documentation reviews Entity Data Model (EDM) supplied by the EF. As the reader may
and informal discussions with stakeholders. Second, the study recall, by rich domain models we understand models that describe
design maintained a chain of evidence [48] by following a well- a complex business domain by using a number of advanced
defined multi-stage process (see previous subsection) spanning object-oriented techniques, such as inheritance and design
from initial positing of research questions to deriving ultimate patterns [25]. However, several studies of domain-driven design,
case study conclusions. handling persistence and applying object/relational mapping tools
Admittedly, there exists an external validity threat in that only one in industrial projects exist.
company was investigated. This could largely undermine the Landre et al.[30], presenting their experiences from building an
potential for making generalizations beyond the immediate case. oil trading application with an object-based domain model in its
However, this threat cannot be minimized to any significant extent core, describe how Java Data Objects (JDO) - based mapping
at the present stage as more research is needed to corroborate or approach was used to persist domain entities. The authors argue
disprove the case study findings in a wider industrial context. that domain-driven design along with a proper object-relational
There is also a construct validity threat in this case study. The mapping tool generally improved system performance and
danger to construct validity comes from the fact that data reduced the code size relative to some of their existing legacy
collection methods and resulting evidence may be biased due to applications. An important improvement came from incorporating
investigator subjectivity [45, 48]. To counteract this we used a Repository domain pattern [22]. According to this pattern all
persistence-related code was encapsulated inside a repository and
4

13. the resulting business logic code, oblivious of persistence can be evaluated. The authors also present the results from a
infrastructure, operated only on pure business entities. This in turn qualitative evaluation of existing solutions. Their study included
resulted in cleaner code, which facilitated communication within such tools as object/relational mapping tools, object-oriented
the team. However, it was difficult at first, as authors noted, to database systems and orthogonal persistence systems.
change the mindset of database-oriented developers to an object- Researchers and practitioners have developed a number of
oriented way of formulating JDO queries. The JDO mapping solutions helping to mitigate or altogether eliminate the object-
approach did eventually pay off as developers no longer had to relational impedance mismatch. Some of the proposed solutions
concern themselves with the minute details of the relational are discussed below.
database schema and instead focus on core business entities. Still,
while the authors presented important drivers behind migrating to One solution that completely prevents the mismatch is to use
a mapping layer, no meaningful guidelines were offered on how object-oriented database systems (OODBS). OODBS enable a so-
mapping tools should be integrated into domain-driven called transparent persistence [36], whereby both persistent
development or what role domain modeling should play in the objects and in-memory objects are accessed in the same way. This
process. is achieved through storing objects directly rather than
transforming them to relational constructs before persisting [49].
Wu [47] presents an enterprise system intended to assess human As a result only one object-based domain model needs to exist in
performance. The system domain model was generated by the the application, resulting in overall design improvements [49].
Entity Object framework3. This framework closely resembles However, predictions of a wide adoption of OODBS did not
Repository pattern [22]: it encapsulates all persistence-related materialize as they have achieved only a 2% share of the
issues through object-relational mapping and thus enables a international database market [32]. Relational databases remain
developer to work with a pure object-based domain model. The the dominant persistence mechanism [15].
author claims that the architecture based on the Entity Object
framework effectively decoupled the database from the rest of the Another interesting approach to persistence is orthogonal
application and improved the overall design since developers no persistence [5, 40]. Orthogonality in this sense considers
longer had to be aware of the intricacies in the relational database persistence as merely an aspect of an application. The basic tenet
schema. Still, the author fails to examine the framework in the behind orthogonal persistence is the obliviousness of the
wider context of domain-driven design and domain modeling. persistence concern. Once persistence has been “aspectisized”, the
rest of the application can be built as if no data needs to be
A promising approach to domain-driven design is proposed by persisted. The persistence mechanism can be plugged in at a later
Philippi [38]. The author discusses experiences from developing a time. There have also been some attempts to embed persistence
model-driven tool that allows visually modeling an object domain capabilities directly into a programming language [12].
model and then automatically generating persistence-related code
and data definition language (DDL) SQL queries. The mapping
between domain objects and relational tables is specified with a 4. THEORETICAL FRAMEWORK
wizard tool. Essentially, an application developer specifies This section seeks to define important terms actively used
different trade-off criteria, such as maintainability, throughout the thesis report. It contrasts two approaches to
understandability, which in return generates mappings for a addressing domain logic in enterprise applications. The section
chosen object-relational tool vendor. The system currently then introduces the basic concepts of domain-driven design.
supports TopLink. The author also discusses how mappings of Finally, the section delves into the Entity Framework: its
attributes, associations and inheritance hierarchies can be architecture and its basic premise of conceptual data
performed. He also makes a seminal analysis of different programming.
mappings in terms of understandability, maintainability, storage 4.1 Structuring domain logic
space and performance. We actively used the results from this Oldfield [37] discusses three types of requirements that any
analysis in formulating mapping patterns which are a part of the application software has to fulfill. First, there are requirements
Entity Framework guidelines. Finally, the author argues that the originating from users, which determine system’s purpose and
starting point for the automatic generation of object-relational how the system is used. These requirements are usually captured
mappings is an application object model – a domain model. in Use Cases [10]. Second, there are non-functional requirements
Generally, the problem of a paradigm schism between object and that capture quality attributes of a system: reliability, performance,
relational models has been a longstanding one [18] and has been security and many others. Finally, there are domain requirements.
widely studied [4, 7, 11, 15, 25, 29, 33, 46]. Several pattern A domain of a software product is the subject area in which the
languages have been created, which catalogue best practices in user applies this product [22]. Domain requirements capture
mapping objects to relations [15, 29]. We used a number of these essential domain concepts, their relationships and important rules.
patterns to complement our own mapping patterns, especially Business rules, for example, constrain and control the way a
when it came to mapping the EDM to a relational model. business operates. In this report, we use the term business rules
Moreover, to define the pattern language we consulted [29]. interchangeably with terms like domain logic, business logic or
Cook and Ibrahim [18] review numerous issues affecting the application logic. We also use the terms business object, domain
language/database integration and develop these issues into object and business entity interchangeably in this report.
criteria against which different solutions to impedance mismatch Historically, in the object community there have been several
approaches to organizing and implementing business logic in
3
applications. Fowler [25] identified three patterns of organizing
.NET-based enterprise framework for domain-driven design. Available
domain logic in enterprise applications: table-based record set
at http://neo.sourceforge.net/
5

14. (Table Module), procedural (Transaction Script) and domain the database [4, 11]. In fact, recognizing this limitation in
model-based (Domain Model). Table Module and Transaction relational modeling, Peter Chen in 1976 devised the entity-
Script patterns are largely database-driven in a sense that the relationship model approach [17] to conceptual data modeling.
relational model determines the structuring of domain objects and Domain object models, unlike their relational counterparts, model
their relationships. Subsequently, all logic is concentrated in a set conceptual real-world business entities and operate at a higher
of heavyweight application services operating on database table- abstraction level.
like objects (data containers), instead of actual business entities All business logic in the procedural style resides in the business
where they naturally belong. Domain Model (DM) pattern, on the tier within MoneyTransferService. This service performs a
other hand, stresses the importance of decoupling the object transfer of money assets from one account to another. The service
model from the database model and structuring the whole definition executes all business rules (such as overdrafting policy)
application around the object-based domain model4 – a domain- before crediting and debiting accounts.
driven approach [22]. According to this pattern, encapsulating all
domain logic in a set of interconnected business objects (domain Web Tier Web Tier
ASPXController
model) is a way to manage complexity inherent in most
businesses. In the following subsections we contrast Transaction
Script and Domain Model patterns for illustrating two distinct
approaches to structuring domain logic.
Business Tier
4.1.1 Procedural style (Transaction Script) MoneyTransferService
The basic premise behind this style is that all application logic is
organized into a set of procedure-like scripts (“fat services”), each +TransferMoney(in fromAccount, in toAccount, in amount)
of which handles a single request from the presentation layer.
Normally, a single script is responsible for one business Data Tier
-fromAccount
transaction, such as book a hotel room, transfer money from one Account
account to another, etc [25]. Figure 1 illustrates a part of a -accountID
* -accountType 1
banking application5 built with the Transaction Script pattern. -balance
Customer *
The most salient characteristic of this design approach is that -customerID
domain objects/entities (Account, Customer and -firstName BankingTransaction
-lastName 1 -toAccount
BankingTransaction) do not encapsulate any business logic per se. -address1 -transactionID
-address2 -amount
Domain objects in this model represent bare data containers (with -date
1
getter/setter fields), which is in a fundamental conflict with the *
object-oriented paradigm of encapsulating both data and behavior
[23]. In fact, the structure of the database schema largely Maps one-to-one to
determines the design of these objects. Fowler [23] refers to such
a model as anemic domain model – database-driven with no Account BankingTransaction
domain logic. While there is nothing wrong with a domain model accountID transactionID
structure closely resembling that of a relational model (one-to-one accountType amount
mapping), a mechanic derivation of a domain object model from a accountBalance date
database with no regard to the principle of encapsulation could customer_FK fromAccount_FK
toAccount_FK
cause problems in later stages of development. Most importantly,
this could lead to broken abstractions in the application. For
example, a real-world entity Order could be split into several
Order-related tables in the database due to normalization
requirements. Following the procedural pattern, these tables Customer
customerID
would be one-to-one mapped to domain objects in the data tier.
firstName
As a result, the Order entity will be fragmented over a number of
lastName
related objects in the object model and the mental model of the address1
application will be disrupted. It is necessary to remember that a address2
relational model with its mathematical underpinnings may not be
suited for modeling real world domains at a high level of
abstraction. It is a logical representation of how data is stored in Figure 1: Part of a banking application built in a procedural
style
4
Essentially, a domain model is a way to express domain requirements by
This design style has some properties that make it attractive for
explicitly capturing essential business concepts, their relationships and building non-sophisticated enterprise applications [25]. First, it is
rules in a concrete model. easy to add new functionality by implementing a new transaction
5 script. Second, it does not require significant object modeling
This example was inspired by the presentation made by Chris
skills. In fact, some enterprise application frameworks (e.g. J2EE
Richardson on “Improving Application Design with a Rich Domain
Model”. Available at
http://www.parleys.com/display/PARLEYS/Improving+Application+De
sign+with+a+Rich+Domain+Model?showComments=true
6

15. EJB6) even encourage this style. However, a significant application design with the domain model at the core – domain-
disadvantage of this approach is that it does not scale well to driven design. Next sub-section addresses this approach at length.
complex business domains. As more and more functionality is
added, transaction scripts tend to multiply and swell in size. As a
result, the potential for the same business logic to be repeated in There are a number of benefits to having a domain model at the
several places becomes more pronounced, which seriously core of the application design. Firstly, because the domain model
undermines application maintainability. Another problem with the is decoupled from the relational model, such design reflects the
style, as we mentioned, is that the resulting object model is largely reality of business better. Clients to a domain model are able to
database-driven – hence, some adverse implications for operate in terms of real business concepts. Secondly, a domain
application abstractions. model represents a model of business and its core concepts. These
concepts rarely change and are quite stable. Therefore, by
4.1.2 Domain Model style encapsulating all business-related functionality in a domain
The Domain Model pattern prescribes offloading all the domain model, it becomes possible to reuse the model in a new context
logic from services (transaction scripts) and encapsulating it (new applications, for example). Finally, as Evans [22] stresses, a
inside a domain layer – a layer of objects that model the business domain model represents a ubiquitous language – a common
area. Essentially, the business logic is modeled as operations on language shared by domain experts, developers, managers and
classes and spread among a collection of domain objects. See other stakeholders. Ubiquitous language facilitates shared
Figure 2 for the comparison of the two design approaches. understanding of the domain, and, ultimately, leads to better
software that is more in line with the user concerns and needs.
4.2 Domain-driven design
Evans [22] sees domain-driven design (DDD) as the
“undercurrent of the object community”. The principles of DDD
have been known for a long time, yet only recently has the DDD
gained increased attention and interest from software developers
[22]. The fundamental premise behind the DDD is that most
software projects should primarily focus on the problem domain
and domain logic. Application design should be based on a
domain model. This is achieved by closely mapping domain
concepts to software artifacts. DDD should not be viewed as a
software development process in its own right. Rather, it is a set
of guiding principles, practices and techniques aimed at
facilitating software projects dealing with complicated domains.
DDD should be applied in the context of an iterative development
Figure 2: Transitioning from procedural database-driven process, where developers and domain experts have a close
design to domain-driven design (adapted from Richardson7) relationship.
Most importantly, a domain model is intended to be purely The centerpiece of the DDD philosophy is a domain model [22].
conceptual: classes in this model directly correspond to real-world A domain model represents essential knowledge about the
objects. It is, therefore, likely that the domain model will often problem area. It is a tool for overcoming information overload and
diverge from its relational counterpart. To ensure that data can be overall complexity when a development team attempts to extract
transparently passed between the two potentially diverging models domain knowledge from system users. A domain model “is not
(due to object-relational impedance mismatch), Fowler [25] just the knowledge in a domain expert’s head; it is a rigorously
suggests that a Data Mapper be used. The sole purpose of the Data organized and selective abstraction of that knowledge” [22] (p.
Mapper is to move “data between objects and a database while 3).
keeping them independent of each other and the mapper itself” Fowler [25] offers a relevant discussion of domain models. A
[25]. It could be understood as a translator that performs data domain model captures the business area in which an application
transformations as it crosses object-relational boundary. Object- operates. It models essential business entities (domain objects)
relational mapping tools emerged as a result of the need for and their intrinsic qualities such as attributes or constraints from a
automatic data translation and mapping of object models to conceptual perspective. But above all, a domain model
database models. To date, a number of commercial (LLBLGen encapsulates all domain logic, which might include business rules,
Pro, Apple WebObjects) as well as open source constraints and other important components.
(Hibernate/NHibernate as the most popular) solutions exist. In
fact, a whole new discipline appeared as a result of pursuing Importantly, a domain model is not necessarily a diagram or some
other illustration, rather, it is the notion that a diagram seeks to
convey. A diagram can communicate a model, as can more textual
6
It is notable how its reference architecture encourages Transaction Script representation. However, considering that object-orientation is
thinking: Enterprise Java Beans (EJB) implement procedures by largely based on modeling real-life objects, object-oriented
operating on an anemic Entity Bean-based model. models (namely, a class diagram) have become a de-facto
7
See
standard for capturing domain knowledge (see Appendix C).
http://www.parleys.com/display/PARLEYS/Improving+Application+De In a sense that DDD espouses a model as the primary artifact in
sign+with+a+Rich+Domain+Model?showComments=true software development, it is closely related to model-driven
7

16. Interface
development (MDD) philosophy. Both methodologies strive to
User
reduce complexity inherent in application domains by raising the
level of abstraction in software construction to a level that is
closer to a problem domain [42]. However, unlike DDD, MDD
stresses automatic generation of programs based on corresponding
models [43]. In this context, DDD does not see the domain model
as a platform for code generation. Rather, the domain model in
Application
DDD is considered to be a facilitator of a common language
shared by all stakeholders [22]. Moreover, instead of having just
one central model (e.g. a domain model in DDD), MDD
prescribes producing a number of models targeted at different
abstraction levels [1]. Such models may include computation-
independent models (domain models), platform-independent and
platform-specific models [1, 26].
Domain
4.2.1 The building blocks of domain-driven design
A domain model seeks to bridge the gap between analysis and
design by addressing concerns belonging to both of the activities.
One can find not only familiar business objects/entities in the
model (business analysis model), but also objects representing
services, repositories and factories (design model). Figure 3 Infrastructure
presents a navigation map of the DDD concepts.
Figure 4: Layered architecture according to DDD
(source: Evans [22])
Infrastructure layer provides technical support for all application
services. Such technical capabilities can include message sending,
persistence for the domain model, etc. Domain layer is the place
where the domain model ‘lives’. It is responsible for representing
business concepts (state) and business rules. Application layer is
supposed to be thin: it only orchestrates use case flows (task
coordination) and then delegates to behavior-rich domain objects
for most domain logic. Finally, the User Interface layer is a
regular front-end of the application. It is either a graphical user
interface (GUI) through, which users feed commands to a system,
Figure 3: A navigation map of the language of domain-driven or a system interface to which external applications can connect
design (e.g. a Web service).
(source: Evans [22])
In the paragraphs to follow, we briefly discuss each of the 4.2.1.2 Entities
building blocks. For a more detailed text the reader is referred to An entity represents a domain object that is defined not by its
Evans’ book on domain-driven design [22]. attributes, but rather by continuity and identity [22]. Entities
usually directly correspond to essential business objects, such as
account or customer. Thus, entities are usually persistent: they are
4.2.1.1 Layered architecture
stored in the database. From database storage comes one of the
From an architectural viewpoint, a domain model comprises a
defining characteristics of an entity: continuity. Continuity means
distinct layer in an application that encapsulates a set of stable
that an entity has to be able to outlive an application run cycle.
business object types [44]. In DDD a domain layer constitutes the
However, once an application is re-started, it should be possible
core of the application design and architecture. It is responsible
to reconstitute this entity. To differentiate one entity from another
for all fundamental business rules. It is in the domain layer that
a concept of identity is introduced. Every entity possesses an
the model of the problem area resides. This appears in sharp
identity that uniquely identifies it in a set. Accordingly, even if
contrast with the procedural approach in Transaction Script where
two entities have the same attribute values, they are considered
all domain logic is concentrated in the application (service) layer.
distinct so long as their identities differ.
Figure 4 illustrates the layered architecture to which most DDD
applications adhere:
4.2.1.3 Services
Services represent concepts that are not natural to model as
entities [22]. Services are responsible for pieces of domain logic
8

17. that cannot be encapsulated in an entity. A service can be subjected to the root. The boundary defines what is inside the
considered as an interface or an entry point into the domain model aggregate and what is outside. The defining characteristic of a
for external clients. A proper service possesses three important root is that outside objects are allowed to hold references only to
characteristics[22]: 1. the operation a service implements directly the root of an aggregate.
relates to a business concept; 2. the service interface is defined in Aggregates play an important role in a domain model. They
terms of the elements of a domain model (intention-revealing provide an abstraction for encapsulating references within the
interface); 3. a service operation is stateless. model. For an outsider, a domain model consists only of
As an example of a ‘good’ domain service, consider the case aggregates and their roots. Clients of a domain model can only
when an application implements a transfer of funds between two hold direct references to aggregate roots. Other non-root objects
bank accounts. The transfer operation directly relates to the should be accessed via traversal. Importantly, should an aggregate
banking domain term “funds transfer”. Modeling the transfer root be deleted from persistent storage, all aggregate members will
operation on one of the entities (e.g. account) would be somewhat also be removed. Also, when a root is saved, the ensuing
undesirable because the operation involves two accounts. Thus, a transaction spans the whole aggregate.
funds transfer operation is best factored into a separate domain
service operating on domain entities (see Appendix C). A service 4.2.1.5 Factories
can be directly accessible from the application or a presentation A factory is a mechanism for creating complex aggregates [22].
layer. An aggregate, as a rule, has to maintain invariants (constraints). A
factory ensures that an aggregate is produced in a consistent state.
4.2.1.4 Aggregates It makes certain that all entities are initialized and assigned an
An aggregate is a set of related entities that can be treated as a identity. So instead of directly creating an object from an
unit for the purpose of data changes [22]. In a system with aggregate via a constructor, a client requests a specific factory to
persistent data storage there must be a scope for a transaction to construct an entire aggregate and return a reference to the
change data. Consider a case when a certain number of related aggregate root.
entities are loaded from the database into the main memory. After
modifying the state of some of the objects a user attempts to save 4.2.1.6 Repository
their work. A database transaction is spun to maintain data A repository represents all domain objects of a certain type as a
consistency during the save operation. However, should the collection [22, 25]. Main responsibilities of a repository are:
transaction apply only to the saved object or should it also apply query databases and return (reconstitute) a collection of objects to
to its related object(s)? Another issue arises when a deletion of a the client, delete domain objects from persistence storage and also
domain object occurs. Should the related objects also be deleted add new objects to persistent storage. It acts as an object-oriented
from the persistent storage? Essentially, an aggregate addresses application programming interface (API) for data, entirely
these issues by identifying a graph of objects that are treated as a encapsulating database access infrastructure. A repository
unit. Any operation performed on an object within the graph contains all database-related queries and object-relational
automatically applies to all other graph members (e.g. a mapping specifications. It acts as an additional layer of abstraction
transaction). Figure 5 illustrates an aggregate. over the domain layer. Accordingly, through a repository only
aggregate roots can be reached. Other objects internal to an
aggregate are prohibited from access except by traversal from the
root.
4.3 The ADO.NET Entity Framework
Microsoft Corporation released the beta 3 version of the Entity
Framework (EF) in the late 2007 [2]. The fundamental principle
behind the EF is that the logical database schema is not always the
right view of the data for a given application. Accordingly, the
main goal of the framework is to build a level of abstraction over
a relational model. This abstraction is realized with the conceptual
data model which is composed of entities representing real-world
objects. In this way, a database application can view data as
conceptual entities rather than as logical database relations. By
introducing a conceptual abstraction over a relational store, the
EF attempts to isolate the object-oriented application from the
underlying database schema changes. In doing so it is very similar
to traditional object-relational mapping tools. However, the EF
also introduces a distinctive feature – the Entity Data Model –
which we discuss in the following subsection. Section 4.3.2
presents the comparison of traditional data access with the SQL
Figure 5: Aggregate (adapted from Evans [22]) Client and new data access with the Entity Framework.
Each aggregate has a root object (Car) and a boundary. The root
is a single specific entity which is considered primary. All other 4.3.1 The building blocks of the Entity Framework
objects (Wheel, Position and Tire) within an aggregate are Figure 6 illustrates the basic elements of the Entity Framework.
9

18. Consisting of conceptual entities and corresponding relationships
ADO.NET Entity Framework the EDM hides the relational model of the database from the rest
of the application. It corresponds to a conceptual layer in the EF.
The EF performs mapping of a conceptual layer to a logical layer
Entity SQL ObjectServices LINQ to Entities (relational model) by introducing two additional layers below the
EDM: mapping specification and storage schema definition.
Storage schema definition is essentially a specification of a
Entity Client relational database model. Mapping specification reconciles the
object-relational impedance mismatch by mapping conceptual
entities in the EDM to relations (tables) in the storage schema.
Entity Framework Metadata Layers 4.3.1.2 Entity client
While the concepts of the EDM and mapping may seem abstract
CONCEPTUAL Entity Data Model at first, during program execution they are made concrete with a
special ADO.NET8 interface – EntityClient. Entity client is a data-
access provider for the EF, which is also called mapping provider.
Entity-to-Relation It encapsulates and handles database and EDM connections. It is
MAPPING mapping specification very similar to a regular SQL Client in ADO.NET, which allows
applications to connect to relational data sources. However, unlike
SQL Client, Entity Client provides access to data in the EDM
Relational database
LOGICAL terms. In this case, the EDM acts as a conceptual database similar
model
to Repository concept from DDD.
4.3.1.3 Entity SQL
When an application uses the Entity Framework and its mapping
provider to access data, it no longer connects directly to the
Datasource database. Rather, the whole application operates in terms of the
EDM entities. Therefore, it is no longer possible to use the native
database query language for retrieving data. The EF enables
Figure 6: Entity Framework architecture (adapted from [4])
querying against the EDM by introducing a query language –
EF is claimed to largely overcome impedance mismatch problem Entity SQL (eSQL) [4]. The overall structure and syntax of Entity
by elevating the level of abstraction in data programming from SQL is very similar to those of the standard SQL (usual SELECT-
logical (relational schema) to conceptual [4, 11]. This implies that FROM-WHERE sequence). Unlike the SQL, eSQL introduces
the application can be oblivious of the relational schema by additional features such as support for navigational properties (it
accessing persistent data through an explicit conceptual model is possible to traverse entities instead of using JOIN) and support
called Entity Data Model (EDM). EDM abstracts away logical for inheritance.
(relational schema) design from the rest of the application by
exposing high-level business entities as data containers. In this 4.3.1.4 Object Services
way, persistence layer is decoupled from the application layer, Considering that most applications are written in object-oriented
which mitigates impedance mismatch problem. languages and thus operate on objects, the EF introduces Object
Services feature [4]. The EF includes a tool that, given the EDM
4.3.1.1 The Entity Data Model definition, will generate a domain object layer for use in the
The Entity Data Model (EDM) follows the notation of the Entity- application. By using Object Services it is possible to query the
Relationship model [17]. The key concepts introduced by the EDM with eSQL and retrieve strongly-typed objects from the
EDM are [4]: store. In the same manner, once the application has finished
• Entity: entities directly correspond to the same concept in working with objects in memory, it only has to invoke the
the domain-driven design. They are characterized by SaveChanges operation. Subsequently, the mapping provider will
continuity (persistent) and have a unique identity. Entities in persist these objects by transforming them into corresponding
the EDM represent conceptual abstractions over the SQL statements to relational database.
relational model and, therefore, model exclusively real-life
objects. Each entity is an instance of Entity Type (e.g. 4.3.1.5 LINQ to Entities
Employee, Order). At runtime entities are grouped into When it comes to querying databases for data, application
Entity Sets. programmers have to use two languages for this purpose: the
query language and the programming language for manipulating
• Relationship: relationships associate entities to one another. the retrieved data. This not only implies that programmers have to
Currently, the EDM supports three types of relationships: master two distinct languages, but also that queries specified as
association, containment (entities contained are dependent
on the parent entity – similar to object composition) and
8
inheritance. ADO.NET is a set of software components that can be used by
application developers to access data and data services in .NET
environment.
10