2.3k
views4
comments

I want to define persistent business classes in F#. These are often interrelated - one type referring to the other, another containing a collection typed for a third and so on. The only way I have found in documentation to declare interrelated types is to use the keyword "and" to chain them all together into one declaration.

This is not suitable at all for my use case. Even if I assume that business functionality will be implemented outside the classes in a more functional manner, the size of a typical class hierarchy makes it practically impossible to declare all these classes in one single huge block of code. In reality, almost all classes are interrelated somehow in such a hierarchy, and even if they aren't, it's far too complex to analyze all dependencies and "block" the classes together, only to start over again after a few changes.

Is there another way of making this work? Something that works like the "and" keyword, but allows classes to be defined separately, optimally in separate source code files?

Thanks
Oliver

Hi Oliver,

Right, you have to use "and" at the moment.

The use-case is an interesting one - are these classes auto-generated?

thanks

don

By dsyme on 5/20/2008 3:35 AM (permalink)

Hi Don,

Right, you have to use "and" at the moment.
The use-case is an interesting one - are these classes auto-generated?

In the case of our ORM product (XPO), they are typically written manually, but other ORM products that use a bottom-up approach to create business class hierarchies from existing database schemas would have the same problem. In that latter case an ever greater degree of separation is typically used, where the auto-generated part of each class lives in one file and another part, which is edited and extended manually, lives in another (using C# partial classes). My guess would be that a typical size for each of those files would still be in the hundreds of lines of code, so the separation makes a lot of sense really.

To be quite honest, from an OO point of view it seems to me that this restriction is important to almost any significant class structure. The only scenario I can come up with where the restriction wouldn't matter so much would be a very carefully designed architecture that uses dependency injenction throughout. But in my experience that's very rarely the case, and of course it seems like a quite arbitrary restriction on an application's architecture.

I really loved the C# way of doing it when I first used it... order of classes, and distribution across various source files doesn't matter at all. In all OO languages I'd used before C#, this was always a problem, and I'd hate to go back to that.

Thanks
Oliver

By olivers on 5/20/2008 5:30 AM (permalink)

Have you looked at using F# type augmentations instead of partial classes? They provide roughly the same functionality but behave more like C# extension methods that partial classes.

I have often wondered what a large scale “OLTP system”, for want of a better acronym, would look like in F#. Perhaps I’m being naïve, but I think you could go a long way a simplest approach: a UI defined using controls and other common place OO techniques, a business logic layer consisting of modules contain functions that operate on types from the data layer, which would be either code generated from the DB schema or used to code generate the DB schema.

Cheers,
Robert

By Robert on 5/20/2008 8:07 AM (permalink)

Have you looked at using F# type augmentations instead of partial classes? They provide roughly the same functionality but behave more like C# extension methods that partial classes.

Well, we don't use the partial class approach ourselves, I'm just aware that many bottow-up ORM tools do it (our tool is primarily a top-down object persistence tool). I've considered type augmentations for the purpose and I'm afraid I think they don't really do that job well... as far as I could see, they can't access internal class members directly, which means I'd have to pass in a lot of parameters - persistent classes often have lots of members and business logic will need to access many of them. Well, I don't know - it strikes me as suboptimal, but I'll let the competition deal with that part for now ;-)

I have often wondered what a large scale “OLTP system”, for want of a better acronym, would look like in F#. Perhaps I’m being naïve, but I think you could go a long way a simplest approach: a UI defined using controls and other common place OO techniques, a business logic layer consisting of modules contain functions that operate on types from the data layer, which would be either code generated from the DB schema or used to code generate the DB schema.

The way our product works is to analyze class definitions and create the db schema automatically from that metadata. This allows it to be highly flexible towards the backend, and we currently support around 16 different db backends. However, in order to "understand" the class structures correctly, we make certain assumptions about the way things work - nothing that ever appeared to be a problem so far... but for example Option<T> is not recognized as a nullable reference, classes have to have properties for each of their data fields, and types of properties are used in many places to figure out which database tables must have relations to others. So that's part of the problem - in order to be compatible with the product, my implementation of a business application must be reasonably similar to that I'd create in any other (OO-) .NET language.

I've written up a description of my use case and my concerns in a blog post here: [link:www.sturmnet.org]

I'll be interested to hear comments on that. Thanks for your help!

Oliver

By olivers on 5/20/2008 11:23 AM (permalink)

Topic tags

Built with WebSharper

Home

Answers

Events

Courses

Groups and Conferences

Blogs

Jobs

Developers

Topic tags