Mono 2.11.3 Packs In Microsoft's Entity Framework

Quote:

---

Originally Posted by frantaylor

"Entity frameworks" are nothing more than pure bloat.

If you need an "entity framework" it's a symptom: you are not doing it right.

Use a database with semantics that match your application, and you don't need no steenkin "entity framework".

How nice of Microsoft to encourage bad software design.

Leave it to Microsoft to come up with designs like this:

- developer wants to store key-value pairs

- "entity framework" creates SQL queries to model "key-value" store

- SQL database parses SQL queries and performs "key-value" operations on its underlying database.

So here we have creation of SQL code and the subsequent parsing of this SQL code for NO REASON WHATSOEVER.

Yee-haw!

---

Let's say you're a developer that made your small application that stores a contact list. Later you noticed that you rewrite every time your algorithms of searching, filtering and such. And the most natural choice to not redo them and to not think too much on how you store them, etc. to use Linq and as a backend code to use a database.
Entity can create in basically no time this part.
Also Entity handles typical cases (that most developers writing their .ini or .xml files in the back will not do it) like: schema changes, migrations, changing the backing store and even the database type in a transparent way.
Can you do it better? Maybe! But certainly the Entity solves problems that most novices will not know how to overcome, or even they will do it, they will do it badly.
Another reason why people should use Entity is the way to make a website: MVC3 (or MVC4) is great to make fairly fast a website, but setting a database is painful, so is easier to make with your own collections first (in Entity parlance is "Code first" and after that make a backing database).
At the end Entity brings a native objects ORM that has maybe a performance hit, but it works smoothly with minimum code for most users.

Quote:

---

Originally Posted by ciplogic

Let's say you're a developer that made your small application that stores a contact list. Later you noticed that you rewrite every time your algorithms of searching, filtering and such. And the most natural choice to not redo them and to not think too much on how you store them, etc. to use Linq and as a backend code to use a database.
Entity can create in basically no time this part.
Also Entity handles typical cases (that most developers writing their .ini or .xml files in the back will not do it) like: schema changes, migrations, changing the backing store and even the database type in a transparent way.
Can you do it better? Maybe! But certainly the Entity solves problems that most novices will not know how to overcome, or even they will do it, they will do it badly.
Another reason why people should use Entity is the way to make a website: MVC3 (or MVC4) is great to make fairly fast a website, but setting a database is painful, so is easier to make with your own collections first (in Entity parlance is "Code first" and after that make a backing database).
At the end Entity brings a native objects ORM that has maybe a performance hit, but it works smoothly with minimum code for most users.

---

In other words it's the new "Microsoft Access": quickly create inefficient applications that use huge resources, are unscalable, and must be re-written from scratch when they need to be scaled.

Toys for boys

Quote:

---

You think people who file bugs, and do testing of advanced features are suckers?

---

If you're doing QA work on a product that you paid money for, then yes you are a sucker.

What did you pay for?

The "It's only a prototype" trap:

Boss says to developer: "I need you to work up a demo for me. We have a new method for cost accounting and I want to quickly slap something together to show the big boss. Don't worry about efficiency, just whip something up for the meeting"

Developer stays up late for two weeks coding up a demo in MS Access.

Boss brings demo software to meeting.

Boss comes back to developer: "The meeting was a SMASH HIT. We love your software. In fact we want to start using it right away. How soon can you deploy it to 10 sites and 200,000 customers? I told them we could do it by next week. It's ready to go right?"

Developer has two choices:

- Try to make the MS Access solution work (hint: don't go there!)
- Start over again using real technology

Either way the developer misses the deadline and ends up looking bad.

STAY AWAY from these cheesy non-scalable solutions, even for demos. For goodness sake, your demo may actually succeed and they may want to use it!

"CREATE TABLE myData (K INTEGER AUTO_INCREMENT PRIMARY KEY, D VARCHAR(262144))"

--

d = JSON.encode(myObject);

sql.execute("INSERT INTO myData(D) VALUE (?)", d)

key = sql.lastInsertedKey ...


---

sql.execute("SELECT D FROM myData WHERE K=?", key)

myObject = JSON.decode(sql.fetch)

---

really if you want an "entity framework" or an "ORM" for a quick demo application you can just use a two-column table and JSON

No need for all that other crap.

It's over constrained, like a wobbly four-legged stool. Three legged-stools are not overconstrained and they don't wobble.

you've encoded your schema into the database and into the application.

change one and you have to go change the other

why does the database need to know the schema? It's just storing the data and retrieving based on your key

Unless you are actually writing really complex queries with JOINs and subqueries, SQL is gross overkill.

If your project is simple. just use JSON! It's portable to multiple languages and it's human readable.

If your demo is successful, then get rid of the SQL table and replace it with a traditional Berkeley table and you've got speed, multiple-user access, and a "schema-free" database that will never need to be "upgraded" if you decide to add a column.

I hope you realize that the reason to use a DBMS is not just to have a way to store the information. There is much more about it even for small use cases such as:
- transactions
- locking
- ACID
- security
- indexing
- caching
- ....

And there are many types of DBMS with a different feature set. Depending on the use case you may find different DBMS useful for the same application. If the application uses a ORM the underlying DBMS can easily be replaced without touching the application itself.

So yeah... it turns out (as always) that the world is not black and white and that there is no way to generally say a ORM is bad/good.

Quote:

---

Originally Posted by droste

- transactions
- locking
- ACID
- security
- indexing
- caching
- ....
.

---

Berkeley DB has ALL of those, except caching (a good thing, keep reading).

"Indexing"??? Databases don't pick the indexes themselves. You have to pick them and make them. Again if you want an index it's just another Berkeley DB table (that's how the underlying database would do it anyway).

Quote:

---

If the application uses a ORM the underlying DBMS can easily be replaced without touching the application itself.

---

Nope, for example if you are using Hibernate you have to recompile your projected classes if you remove columns.

If you want to deal with removed columns, you can play with views and calculated fields but then you are just slowing down the database even more.

Hahaha on you if you want ACID and caching in the same application!

If you want to cache local results then make a HashMap and just store the keys and data locally. It's FASTER than using the database cache because you can index the cached objects directly.

Again why do you want to carry around so much baggage when JSON.encode and JSON.decode will do all of the work for you?

First: I only listed a few things DBMS do. There is more.

I'm not arguing with you that there are cases where a DB is too much. But I claim that JSON and "schema-free" database are not the solution to all data storage problems. That was the point of my post. If it's a nail, use a hammer, if it's a screw use a screwdriver. And it's not as simple as "is the application small use JSON otherwise DB".

PS: My main problem with JSON is the missing meta data / schema (such as datatypes, constraints, etc...). I recognize that you don't like defined schemes but there are good reasons to have them. This gets very funny if you have dates for example and you get "12.10.11". What the hell does that mean? Which is the year, the month and the day? Is it year 2000+? I know that there is such thing as a JSON schema, but I haven't seen this in real life yet.

Quote:

---

Originally Posted by droste

But I claim that JSON and "schema-free" database are not the solution to all data storage problems..

---

We are not talking about "all data storage problems"

We are talking about the kinds of applications where one might choose to use Microsoft's Entity Framework.

Of course there are applications like payroll and A/R where SQL and a big database are the way to go, because the columns are fixed and you're doing big joins across a dozen tables.

But here we are talking about "free form" applications where the O/R mapping is not straightforward. For example if you are writing a "facebook" type app and you want to let your users have a list of favorite colors, then you are going to have to make some ugly decisions on how to write your DDL if you want to use SQL. Or suppose you want to make networks of friends... This is the entire reason for using an "entity framework", because it's too complex to just code up some simple SQL queries for the job.

Quote:

---

This gets very funny if you have dates for example and you get "12.10.11". What the hell does that mean? Which is the year, the month and the day?

---

As if every computer language today didn't have standard date conversion routines. Geez, just pick ODBC format or something and get on with it. If your application is writing dates like that, that's YOUR bug.

Quote:

---

My main problem with JSON is the missing meta data / schema (such as datatypes, constraints, etc...)

---

Just bundle up the metadata in its own JSON object and store that, too! Again THE SQL DATABASE IS DOING THE EXACT SAME THING UNDER THE COVERS.