Announcement

Collapse
No announcement yet.

Mono 2.11.3 Packs In Microsoft's Entity Framework

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by ciplogic View Post
    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

    Comment


    • #42
      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?

      Comment


      • #43
        "It's only a prototype"

        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!

        Comment


        • #44
          Here's a GREAT "entity framework"

          "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.

          Comment


          • #45
            ORM is bogus anyway

            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.

            Comment


            • #46
              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.

              Comment


              • #47
                Originally posted by droste View Post

                - 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).

                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?

                Comment


                • #48
                  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.

                  Comment


                  • #49
                    Originally posted by droste View Post
                    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.

                    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.

                    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.
                    Last edited by frantaylor; 14 August 2012, 08:45 PM.

                    Comment


                    • #50
                      Originally posted by jrch2k8 View Post
                      sadly nope, microsoft did this not for the goodness of their heart or cause they believe in open source[they not], they do it for this reasons:
                      And this is my problem with the blind Microsoft hatred. Microsoft has some 150,000 people working for them between employees and contractors. Tons of those people are huge fans of Open Source and even Linux. People go to Microsoft for all kinds of reasons, including liking the other people who work there, believing in the products, wanting to advance their careers and getting resume fodder, being interested in the crazy R&D projects that most people never hear about, or just to make lots of money (in many cases, just for long enough to pay off student loans or otherwise get a good financial footing before moving on to a "better" job).

                      When you have that many people there for that many different reasons with a huge variety of backgrounds, it is _absolutely fucking retarded_ to think that everything the company does is some corporate policy handed down by the executives. The company is not under the control of a handful of people. Much of what Microsoft does is driven by the people at the bottom of the totem pole. Ballmer has surprisingly little control, and much less than a CEO in most companies; there's a very, very strong culture within the Microsoft campuses, and people and their opinions and ideas carry a surprising amount of weight. Sometimes this is not a good thing (just because a bunch of people think something is a good idea doesn't mean it is) and other times it is a very good thing (the acceptance of Open Source as a viable means of distributing and supporting software).

                      The rise of Open Source at Microsoft is surely very, very slow. But it's happening because people on the inside keep pushing for it. Not because Ballmer is some kind of mad genius with a 190 IQ that can plan and manipulate the entire world by his every whim.

                      Conspiracy theorists always end up giving _waaay_ too much credit to the people least deserving of it.

                      Comment

                      Working...
                      X