由于循环引用而确定如何对 F# 类型进行排序时出现问题

发布于 2024-09-02 02:34:57 字数 2827 浏览 8 评论 0原文

我有一些扩展通用类型的类型,这些是我的模型。

然后,我为用于 CRUD 操作的每个模型类型提供 DAO 类型。

我现在需要一个函数,它允许我找到给定任何模型类型的 id,因此我为一些杂项函数创建了一个新类型。

问题是我不知道如何订购这些类型。目前我在 dao 之前有模型,但我在 CityDAO 之前需要 DAOMisc ,在 DAOMisc 之前需要 CityDAO ,这是'不可能。

简单的方法是将此函数放入每个 DAO 中,仅引用其之前的类型,因此,State 位于 City 之前,如 State< /code>与City有外键关系,所以杂项函数会很短。但是,这让我觉得这是错误的,所以我不确定如何最好地解决这个问题。

这是我的杂项类型,其中 BaseType 是我所有模型的通用类型。

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

这是一种 dao 类型。 CommonDAO 实际上有 CRUD 操作的代码,但这在这里并不重要。

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
    )

这是我的模型类型:

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);]

FindIdByType 函数的目的是查找外键关系的 id,因此我可以在模型中设置该值,然后让 CRUD 函数执行以下操作:使用所有正确的信息进行操作。因此,City 需要州名称的 id,因此我将获取州名称,将其放入 state 类型中,然后调用此函数来获取该州的 id州,所以我的城市插入还将包含外键的 ID。

这似乎是最好的方法,以一种非常通用的方式来处理插入,这是我当前正在尝试解决的问题。

更新:

我需要研究并看看是否可以在定义所有其他 DAO 后将 FindIdByType 方法注入到 CommonDAO 中,几乎就像它是一个闭包一样。如果这是 Java,我会使用 AOP 来获取我正在寻找的功能,但不确定如何在 F# 中执行此操作。

最终更新:

在思考我的方法之后,我意识到它存在致命缺陷,因此我想出了一种不同的方法。

这就是我将如何进行插入,我决定将这个想法放入每个实体类中,这可能是一个更好的想法。

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

我还没有开始使用 fklist ,但它是 int list 并且我知道每个列名对应哪个列名,所以我只需要执行 例如,用于选择的内连接

这是通用的基本类型插入:

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

如果 F# 可以进行协变/逆变,那就太好了,所以我必须解决这个限制。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

云巢 2024-09-09 02:34:58

这个例子与我习惯的函数式编程相去甚远。但对于相互递归类型排序的问题,有一个标准解决方案:使用类型参数并制作两级类型。我将用相关语言 OCaml 给出一个简单的例子。我不知道如何将简单的示例转换为您正在使用的可怕类型的函数。

以下是不起作用的内容:

type misc = State of string
          | City  of city

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

以下是使用两级类型修复它的方法:

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

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

此示例是 OCaml,但也许您可以推广到 F#。希望这有帮助。

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.

无人接听 2024-09-09 02:34:58

F# 直接支持相互递归类型。考虑以下鸡/蛋类型定义:

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

要点是使用“and”运算符一起声明相互递归类型(而不是两个单独的类型)

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)

原谅我要高飞 2024-09-09 02:34:58

如何消除 DAOMisc.FindIdByType,并将其替换为每个 DAO 类中的 FindId? FindId 只知道如何找到它自己的类型。这将消除对基类和动态类型测试的需要,以及 DAOMisc 和所有其他 DAO 类之间的循环依赖关系。 DAO 类型可以相互依赖,因此 CityDAO 可以调用 StateDAO.FindId。 (如果需要,DAO 类型可以相互依赖。)

这就是您所说的“简单的方法是将这个函数放入每个 DAO 中......但是,这让我觉得错误” ……”?我不确定,因为你说该函数仅引用它之前的类型。我在这里提出的想法是每个 FindId 函数只知道它自己的类型。

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.

扛起拖把扫天下 2024-09-09 02:34:57

在F#中,可以定义相互递归类型,也就是说,你可以定义两个需要互相引用的类型,并且它们会看到对方。编写此语法的语法为:

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

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

此语法的限制是两种类型都需要在单个文件中声明,因此您不能使用典型的 C# 组织每 1 个文件 1 个类型。

正如 Norman 指出的那样,这不是典型的功能设计,因此如果您以更具功能性的方式设计整个数据访问层,则可能可以避免此问题。不过,我想说,在 F# 中结合函数式和面向对象风格并没有什么问题,因此使用相互递归类型可能是唯一的选择。

如果您首先为这两种类型定义接口,那么您可能可以更好地编写代码 - 这些接口可能需要也可能不需要相互递归(取决于一个类型是否在另一个类型的公共接口中使用):

type ICityDAO = 
  abstract Foo : // ...

type IDAOMisc = 
  abstract Foo : // ...

这具有以下好处:

  • 在单个文件中定义所有相互递归接口不会降低代码的可读性
  • 您可以稍后引用这些接口,因此不需要其他类型相互递归
  • 作为副作用,您将拥有更多可扩展的代码(感谢接口)

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)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文