3 ms·

also without an ORM do you just hand roll all your object graphs? I'm picturing a sea of builders and factories which amount to a hand rolled ORM anyway. Or are

by orclev 13y ago

also without an ORM do you just hand roll all your object graphs? I'm picturing a sea of builders and factories which amount to a hand rolled ORM anyway. Or are you practicing stringly typed programming? Ultimately in any strongly typed language you're either going to make/use some kind of mapper or else abandon typing and use maps/dicts which raises the question of why you're using a strongly typed language in the first place.

wtetzner 13y ago
First, you can have strongly typed languages that aren't object oriented. Instead of using maps/dics, you could use records. The thing I don't like about ORMs as they are typically handled is that you map objects to tables up front, and those are the things you can query for. Using something like Linq, you can more easily treat your database as relational, and still return strongly typed objects. These objects can be the thing you wanted to return from the query, which is not necessarily mapped directly to the entities in the database. I like this approach more, since you still get one of the main advantages of a relational database: you can get the data in the shape you want, not in the shape it's stored.
- camus 13y ago
  most ORMs have a query language too, it's not just "Linq". Orms are good for development purposes and you can always do raw SQL queries within ORMs at some point.
  - wtetzner 13y ago
    The thing that's nice about Linq is the integration. You can directly reference variables in the things you're querying, and then either fill in an instance of an existing class, or generate an anonymous object. For example: var query = from c in customers join o in orders on c.ID equals o.ID select new { c.Name, o.Product, Address = c.MailingAddress }; Of course, anonymous objects in C# can be a pain in the ass, since you can't usefully return them from a method. Something like Scala's structural types would solve that problem. I don't really like C# that much as a language, but I do like the Linq approach.
- cmelbye 13y ago
  Could you explain this a bit more in depth if you have a chance? This is extremely interesting, but I'm not familiar with terminology associated with strongly typed languages. What do you mean by using records instead of maps?
  - wtetzner 13y ago
    You can think of a record like a C struct. It's key value pairs, but the keys and their types are chosen at compile time. There are no methods or anything on them, they are just data. An example from OCaml: type person = { first_name: string; last_name: string; age: int } In a language that has some form of anonymous records (like C#'s anonymous object) and structural typing, this would let you work with relations in your language, much in the way you'd use them in SQL. I personally like treating data as data. It should be immutable, and therefore there is no state to hide, which means there isn't much value in your types being objects. It also allows for nice things like pattern matching to work with your data.
    - orclev 13y ago
      You still need some kind of mapper though to go from the SQL results to your record type, even if it's using convention such as the records fields are named the same as the table columns you're pulling from. I'm not arguing that for instance Hibernate is awesome, just that you need something to fill that gap, and you can do a lot worse than Hibernate, particularly within the limitation imposed by Java. Personally I prefer something like this ( http://hackage.haskell.org/package/esqueleto-1.3.4.2/docs/Database-Esqueleto.html http://hackage.haskell.org/package/esqueleto-1.3.4.2/docs/Da... ), but will usually settle for Hibernate or similar in less powerful languages like Java.
- adamonduty 13y ago
  > you can get the data in the shape you want, not in the shape it's stored. If you build a database view, you can often trick an ORM into thinking its a table.

by orclev 13y ago

wtetzner 13y ago

First, you can have strongly typed languages that aren't object oriented. Instead of using maps/dics, you could use records. The thing I don't like about ORMs as they are typically handled is that you map objects to tables up front, and those are the things you can query for. Using something like Linq, you can more easily treat your database as relational, and still return strongly typed objects. These objects can be the thing you wanted to return from the query, which is not necessarily mapped directly to the entities in the database. I like this approach more, since you still get one of the main advantages of a relational database: you can get the data in the shape you want, not in the shape it's stored.

camus 13y ago
most ORMs have a query language too, it's not just "Linq". Orms are good for development purposes and you can always do raw SQL queries within ORMs at some point.
- wtetzner 13y ago
  The thing that's nice about Linq is the integration. You can directly reference variables in the things you're querying, and then either fill in an instance of an existing class, or generate an anonymous object. For example: var query = from c in customers join o in orders on c.ID equals o.ID select new { c.Name, o.Product, Address = c.MailingAddress }; Of course, anonymous objects in C# can be a pain in the ass, since you can't usefully return them from a method. Something like Scala's structural types would solve that problem. I don't really like C# that much as a language, but I do like the Linq approach.
cmelbye 13y ago
Could you explain this a bit more in depth if you have a chance? This is extremely interesting, but I'm not familiar with terminology associated with strongly typed languages. What do you mean by using records instead of maps?
- wtetzner 13y ago
  You can think of a record like a C struct. It's key value pairs, but the keys and their types are chosen at compile time. There are no methods or anything on them, they are just data. An example from OCaml: type person = { first_name: string; last_name: string; age: int } In a language that has some form of anonymous records (like C#'s anonymous object) and structural typing, this would let you work with relations in your language, much in the way you'd use them in SQL. I personally like treating data as data. It should be immutable, and therefore there is no state to hide, which means there isn't much value in your types being objects. It also allows for nice things like pattern matching to work with your data.
  - orclev 13y ago
    You still need some kind of mapper though to go from the SQL results to your record type, even if it's using convention such as the records fields are named the same as the table columns you're pulling from. I'm not arguing that for instance Hibernate is awesome, just that you need something to fill that gap, and you can do a lot worse than Hibernate, particularly within the limitation imposed by Java. Personally I prefer something like this ( http://hackage.haskell.org/package/esqueleto-1.3.4.2/docs/Database-Esqueleto.html http://hackage.haskell.org/package/esqueleto-1.3.4.2/docs/Da... ), but will usually settle for Hibernate or similar in less powerful languages like Java.
adamonduty 13y ago
> you can get the data in the shape you want, not in the shape it's stored. If you build a database view, you can often trick an ORM into thinking its a table.