Facil generates strongly typed F# data access source code from SQL queries and stored procedures.
Facil is an F# source code generator that creates strongly typed data access layers from SQL Server stored procedures and scripts. It transforms SQL queries into callable F# functions, providing type safety and reducing boilerplate code. The tool is designed to integrate seamlessly into F# projects, offering a fluent API for database interactions.
F# developers working with SQL Server who need type-safe, maintainable data access layers without the overhead of traditional ORMs or type providers.
Developers choose Facil for its simplicity, performance, and avoidance of type provider issues. It generates plain F# code that can be version-controlled, works reliably in CI/CD, and offers a flexible configuration system for complex database scenarios.
Facil generates F# data access source code from SQL queries and stored procedures. Optimized for developer happiness.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Generates F# code with full type inference for parameters and result sets, eliminating runtime errors and providing IntelliSense support, as highlighted in the README's emphasis on avoiding boilerplate.
Offers a discoverable, succinct syntax for executing queries with minimal boilerplate, improving developer productivity through a clean, fluent-style API demonstrated in usage examples.
Highly configurable via YAML, supporting regex/glob patterns for procedures/scripts, custom DTOs, and ValueOption usage, allowing fine-tuned control over code generation.
Uses efficient async read loops written in C# and direct DTO mapping to minimize allocations, making it suitable for high-performance scenarios as noted in the README.
Requires SQL Server access at build-time for code generation, which complicates CI/CD pipelines and offline development, as admitted in the setup requirements and FAQ.
Type inference in scripts has limitations due to SQL Server's sp_describe_undeclared_parameters, forcing manual parameter type specifications in YAML for complex cases, adding overhead.
Cannot directly integrate with SSDT .sqlproj files, as stated in the FAQ, forcing reliance on deployed databases and increasing the risk of schema mismatches.