Problem determining how to order F# types due to circular references

Question

I have some types that extend a common type, and these are my models.

I then have DAO types for each model type for CRUD operations.

I now have a need for a function that will allow me to find an id given any model type, so I created a new type for some miscellaneous functions.

The problem is that I don't know how to order these types. Currently I have models before dao, but I somehow need DAOMisc before CityDAO and CityDAO before DAOMisc, which isn't possible.

The simple approach would be to put this function in each DAO, referring to just the types that can come before it, so, State comes before City as State has a foreign key relationship with City, so the miscellaneous function would be very short. But, this just strikes me as wrong, so I am not certain how to best approach this.

Here is my miscellaneous type, where BaseType is a common type for all my models.

type DAOMisc =
    member internal self.FindIdByType item = 
        match(item:BaseType) with
        | :? StateType as i -> 
            let a = (StateDAO()).Retrieve i
            a.Head.Id
        | :? CityType as i -> 
            let a = (CityDAO()).Retrieve i
            a.Head.Id
        | _ -> -1

Here is one dao type. CommonDAO actually has the code for the CRUD operations, but that is not important here.

type CityDAO() =
    inherit CommonDAO<CityType>("city", ["name"; "state_id"], 
        (fun(reader) ->
            [
                while reader.Read() do
                    let s = new CityType()
                    s.Id <- reader.GetInt32 0
                    s.Name <- reader.GetString 1
                    s.StateName <- reader.GetString 3
            ]), list.Empty
    )

This is my model type:

type CityType() =
    inherit BaseType()
    let mutable name = ""
    let mutable stateName = ""
    member this.Name with get() = name and set restnameval=name <- restnameval
    member this.StateName with get() = stateName and set stateidval=stateName <- stateidval
    override this.ToSqlValuesList = [this.Name;]
    override this.ToFKValuesList = [StateType(Name=this.StateName);]

The purpose for this FindIdByType function is that I want to find the id for a foreign key relationship, so I can set the value in my model and then have the CRUD functions do the operations with all the correct information. So, City needs the id for the state name, so I would get the state name, put it into the state type, then call this function to get the id for that state, so my city insert will also include the id for the foreign key.

This seems to be the best approach, in a very generic way to handle inserts, which is the current problem I am trying to solve.

UPDATE:

I need to research and see if I can somehow inject the FindIdByType method into the CommonDAO after all the other DAOs have been defined, almost as though it is a closure. If this was Java I would use AOP to get the functionality I am looking for, not certain how to do this in F#.

Final Update:

After thinking about my approach I realized it was fatally flawed, so I came up with a different approach.

This is how I will do an insert, and I decided to put this idea into each entity class, which is probably a better idea.

member self.Insert(user:CityType) =
    let fk1 = [(StateDAO().Retrieve ((user.ToFKValuesList.Head :?> StateType), list.Empty)).Head.Id]
    self.Insert (user, fk1)

I haven't started to use the fklist yet, but it is int list and I know which column name goes with each one, so I just need to do inner join for selects, for example.

This is the base type insert that is generalized:

member self.Insert(user:'a, fklist) =
    self.ExecNonQuery (self.BuildUserInsertQuery user)

It would be nice if F# could do co/contra-variance, so I had to work around that limitation.

Decasyllabic

See also https://mcmap.net/q/430846/-f-forward-type-declarations – Rickrickard

@Rickrickard - Until I thought about this other question I didn't consider just using and between several types. It seems like a hack to a flawed design, on my part, but I think it is the best approach. – Decasyllabic

Answer 1

This example is very far from what I'm accustomed to in functional programming. But for the problem of ordering mutually recursive types, there is a standard solution: use type parameters and make two-level types. I'll give a simple example in OCaml, a related language. I don't know how to translate the simple example into the scary type functions you are using.

Here's what doesn't work:

type misc = State of string
          | City  of city

type city = { zipcode : int; location : misc }

Here's how you fix it with two-level types:

type 'm city' = { zipcode : int; location : 'm }

type misc = State of string
          | City of misc city'
type city = misc city'

This example is OCaml, but maybe you can generalized to F#. Hope this helps.

Bosch

I need to reflect on what you are showing here, it seems this may be a better approach than what I am doing. – Decasyllabic

After thinking about what you wrote I realized that you were correct in that my approach was wrong. – Decasyllabic

I had to think for some moments about this nice solution too :) – Coagulum

Answer 2

In F#, it is possible to define mutually recursive types, that is, you can define the two types that need to reference each other together and they will see each other. The syntax for writing this is:

type CityDAO() = 
  inherit CommonDAO<CityType>(...)
  // we can use DAOMisc here

and DAOMisc = 
  member internal self.FindIdByType item =  
    // we can use CityDAO here

The limitation of this syntax is that both of the types need to be declared in a single file, so you cannot use the typical C# organization 1 type per 1 file.

As Norman points out, this isn't a typical functional design, so if you designed the whole data access layer in a more functional way, you could probably avoid this problem. However, I'd say that there is nothing wrong with combining functional and object-oriented style in F#, so using mutually recursive types may be the only option.

You can probably write the code more nicely if you first define interfaces for the two types - these may or may not need to be mutually recursive (depending on whether one is used in the public interface of the other):

type ICityDAO = 
  abstract Foo : // ...

type IDAOMisc = 
  abstract Foo : // ...

This has the following benefits:

• Defining all mutually recursive interfaces in a single file doesn't make the code less readable
• You can later refer to the interfaces, so no other types need to be mutually recursive
• As a side-effect, you'll have more extensible code (thanks to interfaces)

Jeanne

I am probably going to go with an interface, but I am not happy with the solution, as it seems to be kludgy. I think there is something fundamentally wrong with my design. I added an edit on my question about this. – Decasyllabic

Answer 3

F# directly supports mutually recursive types. Consider the following chicken/egg type definition:

type Chicken =
   | Eggs of Egg list
and Egg =
   | Chickens of Chicken list

The point is that mutually recursive types are declared together using the 'and' operator (as opposed to two separate types)

Concise

I believe I had tried your approach and when I wrote my question I couldn't get it to work. F# 3.0 may have made this possible, I haven't tried it at this point. – Decasyllabic

Answer 4

How about eliminating DAOMisc.FindIdByType, and replacing it with a FindId within each DAO class? FindId would only know how to find its own type. This would eliminate the need for the base class and dynamic type test, and the circular dependency between DAOMisc and all of the other DAO classes. DAO types can depend on one-another, so CityDAO can call StateDAO.FindId. (DAO types could depend on one another mutually, if need be.)

Is this what you were talking about when you said, "The simple approach would be to put this function in each DAO... But, this just strikes me as wrong..."? I'm not sure because you said that the function would refer only to the types that come before it. The idea that I am presenting here is that each FindId function knows only its own type.

Snooker

I am trying to reduce as much as I can any repetitive code, and keep my functions as generic as I can, which is why repeating the function in each dao class would be a concern. – Decasyllabic

Your idea was what I went with – Decasyllabic