In my ongoing effort to encourage the adoption of Clojure(Script) and Crux within my C#/.NET/SQL-Server organization, I have encountered push back on the data modeling and persistence front. Basically the push back goes like this: “We just design our classes and Entity Framework does the rest! We just right code like the following: public async Task<IEnumerable<Weighment>> TimeAsync( IDataContext context, DateTime inStart, DateTime inEnd, DateTime outStart, DateTime outEnd) { return await Task.Run(() => { return Persistence.Find(context, w => w.Inbound >= inStart && w.Inbound <= inEnd && w.Outbound >= outStart && w.Outbound <= outEnd); }).ConfigureAwait(false); }” Any thoughts on a response?

Hi @hairfire - I'll have a think and will attempt to form a good articulation. There's the data-first approach - working with data as-is rather than attempting to model reality with types and having to keep pace and deal with changes - I'll ask @malcolmsparks to weigh in also 🙂

I use to work with ORM frameworks such as Hibernate for Java, and so I feel I have some context to draw on. I'd be tempted though to show the alternative - how simple it could be if you're just persisting maps of data and then immediately being able to perform graph queries against it - without the need for boilerplate code which can be stubborn to make changes to. A side by side comparison - showing code, is preferable to getting into a drawn out debate, in my experience!

I've been stressing the schema-on-read, schema-on-write, incremental-schema, sparse-data and data-as-is benefits, and have been pleased with the recognition thereof. Their retorts have typically centered around the ability to use "standard C#" (e.g., x <= y) to define a predicate pre-condition and mutation, all within an implicit transaction that will fail if a stale condition occurs, and built-in one-to-many and many-to-many C# entity accessors. Personally, I've never used Entity Framework, or any ORM for that matter, but I can see the value in the features they describe. I'm intrigued by the idea of specifying data relationships via spec/edn, and creating something that will "generate" accessor functions for Crux.

Any choice is a trade-off, so if something is easy during development, most likely something else down the line will not. Also many things have been written and said against ORM as a system evolves, e.g. leakiness, fighting against the framework, trying to circumvent it, etc. Understanding how the system will evolve, and even spiking likely scenario, should help highlight some trade-offs. But first and foremost, a willingness to explore other ways is required.

Thanks @fmjrey, my I have heard some of my colleagues mention "fighting against the framework" and/or "trying to circumvent it".

Personally, unless a system isn't going to evolve, I'd rather have full control of how data is stored, indexed, and accessed (no SQL generation).

My experience has lead me to the same conclusion! I've always written a storage abstraction layer, and written SQL by hand when the back end store required it.