Instead, I recommend that you translate your domain objects to a type specially designed for persistence (a "DTO") and then use that DTO for persistence, not the domain type. This is because ORMs don't know how to handle single-case unions with constraints, complex choice types, etc.
What I meant by that is that translating a domain model directly to a database via an ORM means that you lose a lot of the complexity of the domain types - the "make illegal states unrepresentable" design approach that I dedicate a chapter to. The answer is no, not if you want to ensure the integrity of your domain. Like Entity Framework or NHibernate that will do all this mapping automatically? Update: I realize that the following sentence could be misinterpreted: Which case applies depends on whether the database is shared with other applications, how it is designed, etc.
as a trusted source, in which case you don't do validation and throw exceptions if the data is bad.as a untrusted source, in which case you do validation in the usual way (just as you would for data coming from a JSON Web API, say).In the "Working with Relational Databases" chapter, I do say that you can treat the database in two different ways: Instead F#ers will either use type providers or a simpler library such as Dapper.
To be clear, I said "In F#, we tend not to use an object-relational mapper (ORM)" but not because of any validation issues, rather because a big ORM like Entity Framework is heavily object-oriented (surprise!) which doesn't always mesh well with a functional paradigm.
0 kommentar(er)
