I’m new to F# but would like to start building an API with it.
I have previously built c# API’s. In those we layer the architecture between models (being in the controllers), the domain DTO’s in the services and finally in the data layer if there needs to be any persistence.
Between these layers we use Automapper to map the types up and down the layers keeping a clean separation, for example none of our domain objects can have anything null in them (we use a maybe/option) and cater for this in our mappings between the objects.
I have seen examples of building API’s with F# but no good examples on architecture. I have also see Automapper used on a stack overflow with F# but it seems hacky to me.
I’m just wondering what people do. Do you use something like Automapper in F#, do you keep a separation between your models and domain DTO’s? do you care?
It’s not a question that seems to get asked a lot. A great many blogs using Giraffe or a video on youtube on “getting started with asp.net core” etc but what I’m looking for guidance on is Enterprise best practice. I want to start using F# right and making these architecture decisions and getting them right is critical especially if there are those around you who are critical to begin with.
Mostly reposted from SO. I’m not sure which thread you prefer to maintain. Which is the original and which is the repost? Then we can mark one as a duplicate.
DTOs are intermediate serialization-friendly objects. It’s a lot of code to create these, and then you have to create hints about the maps if mapping automatically, and you have introduced reliance on reflection (slow), introduced a type-unsafe automation system in your code, and end up with inefficient serialization.
Just as much work as writing the serialization directly.
Would you expose a database DTO from the data layer of your application to the top level, say as an object that gets serialized to JSON and exposed through a controller?
To quote the AutoMapper website AutoMapper is a simple little library built to solve a deceptively complex problem - getting rid of code that mapped one object to another. So essentially in C# when using in our API we have similar DTO objects at different levels of our application. AutoMapper helps (and can sometimes map automatically) one model DTO to a domain DTO , this keeps a separation of concerns between the layers, and allows us to map classes that may contain null in the model layer to values in domain layer to have an Option which we can add in a custom mapping.
Really what I’m asking is, do you as an F# developer worry about a separation of concerns between different layers of your application? Do you have Model, Domain, Data layers in your application? Do you follow anything like onion architecture?
I started this thread first and wrote the SO one second.
Why do you need a library (AutoMapper) to construct an object from another? The constructor will work just as good and won’t hide logic from you while reading the code. Let go of AutoMapper and just use what is already there in the language. The constructor of a class is the most important method (IMO).
I personally do not use AutoMapper as a matter of principle. I prefer explicit mapping between Domain Types and Web/persistence DTOs, although I can appreciate that some people may prefer a “semi-auto” solution like AutoMapper. My reasoning is that the shape of DTOs will usually be determined by the type of web framework (json serialization method for example) or the persistence mechanism (eg. Dapper). IMO, doing the mapping explicitly is less likely to allow peculiarities of the web/persistence frameworks leak into the domain code.
Domain types, on the other hand, are designed to describe the domain as precisely as possible. Domain models in F# typically make heavy use of discriminated union types, which don’t translate well to Json or SQL dtos.
The way I typically design applications is by starting with the Domain types and the business logic. Once I’m certain all this works (via unit tests for example), then i work my way outward to the boundaries of the application, which usually includes a web interface and persistence interface. I write “adapters” that do the translation between the domain types and the adapter-specific implementations that use their respective libraries/frameworks for web and persistence.
At CAknowledge.com, We have built a whole product from the ground-up in F#. It’s been running in production for a couple of years — this has been a great experience for us. he expressiveness and power of F# has resulted in shorter build cycles, simpler business logic (with fewer bugs!) and the ability to quickly evolve the product.
Type Providers have let us add support for a lot of data formats (Government formats, Excel files, third party sources) very quickly. Pattern matching has made it possible to simplify complex business logic. F# has been a joy to work with, and we’re using it more and more throughout our products now.