Coffeehouse Thread

20 posts

Is Mega-Microsoft going to destroy .NET?

Back to Forum: Coffeehouse
  • User profile image
    vesuvius

    For the last week or so I've been turning over in my mind this post by Krzysztof Cwalina. In it there is an admission of duplication in databinding models for WPF and WF, and a different dependency property system for both as well.

    .NET 3.5 SP1 brings the ADO.NET entity framework, which contains pretty much all of Linq to SQL. The only problem is, again this is duplication by the C# an ADO.NET teams. The CTO of DevExpress has a pretty good write up here.

    What I especially like is one of the comments
    ----------
    In case of LINQ to SQL vs. EntityFramework, these 2 are really just 2 contenders in a field that's including .NET Persistence, BBADataObjects, DataObjects.NET, Data Tier Modeler for .NET, DotNorm, Eldorado.NET, Enterprise Core Objects (ECO™), Entity Broker, eXpress Persistent Objects for .NET, FastObjects.NET, JC Persistent Framework, LLBLGen Pro, ModelWorks, Nhibernate, Nolics.NET, Norm, Norpheme, ObjectBroker, ObjectSpaces, ObjectSpark, Objectz.NET, OJB.NET, OPF.Net (Object Persistent Framework), ORM.NET, Pragmatier Data Tier Builder, RapTier, Sisyphus Persistence Framework, TierDeveloper, Bob.NET, ObjectPersistor.NET, Genome (and I've probably overlooked quite a few). You might notice that DevEx also contributes to that list.
    ------------

    Aside from the duplication, is is really worth getting excited about the ADO.NET entity framework? Will it just not contain bits and pieces from the exhaustive list above?

    With the advent of PDC 08 in October and C# 4.0, it is certain that dynamic features are imminent, but I still truly believe .NET 2.0 is still sufficient and the bigger .NET becomes, in some ways the worse it gets.

  • User profile image
    W3bbo

    Three words: "Visual Studio Integration"

    Oh, and "free (as in freedom) for any work"

    Which cuts out a lot of those contenders.

    As for Linq-to-SQL (DLinq) vs. ADO.NET Entities: I don't believe they're directly competing. DLinq is a much simpler system that generates 1:1 entity classes and not much more, which makes it perfect for simple applications, whereas ADO.NET Entities provides the power needed for more complicated things, but overkill for simpler, RAD scenarios.

    On the plus side, this does mean an end to Typed Datasets. This can only be a good thing.

  • User profile image
    stun

    I agree that the .NET Framework is getting bigger.
    But I am pretty sure that Microsoft will guide its growth in a more gradual process.

    The Java J2EE world has so many choices (e.g., Struts, Java Server Faces, NHibernate, Ant, etc etc...) due to the Open Source efforts.
    This gives us, the developers, many choices to choose from instead of having to stick with what was given to us.


    The Entity Framework and MVC Framework are allowing us to use alternative approaches and methods to solve the problems we have.
    It all comes down to the developer's choice and vision and how comfortable he is with using what is available out there.


    In my opinion, as long as there are alternatives out there and different way of doing things, I think it is better for the ecosystem.
    Sure, it might get confusing to choose from for inexperienced people, but that is the whole reason why *basic* out-of-the-box functionality is enough to do many things.
    The developer just needs to decide on what would be the most effective way and picks up new technologies and learn them on his own.

    Just my 2c

  • User profile image
    PerfectPhase


    As others have said I don't see L2S and EF at odds, L2S is in effect direct binding to the DB schema, EF adds a lot more and is a lot more complex and I don't think will fully mature for a few more versions.  sometimes it's nice to have a simple framework that does overwhelm you on first use.  L2S is pretty much done and doesn't need to go any further, if it does then it starts treading on EF's turf.   Would be nice to have a option for L2S to migrate the model to EF.

    I think the other big thing is MS had to ship a DB LINQ provider when LINQ was released and there was no way EF was going to be ready.

    Another sign of things to come is the penertration of EF into other framework components, that's something we never saw with datasets.

  • User profile image
    staceyw

    Not sure.  I was confused about the overlap at first, but now I see what they did.  They *delivered code with L2S a year ago.  EF is just out.  So they had to deliver something with first linq and not wait until EF was cooked.  Plus EF, as others said, is a different product with different goals.  It like saying they should not develop Word because they already have Notepad or visa-versa.

  • User profile image
    Minh

    I think it's irrelavant how big .Net gets. Take .Net 2.0. I've given up the hope that .Net can be a general development platform (distributed over the net), simply because you can't tell people to download a 25 MB install. The opposite is true for Silverlight, of course.

    So, if the redistributable doesn't matter anyway, then it can grow as much as it needs to. At which point, size becomes choice, and the more choice, the better.

  • User profile image
    littleguru

    They didn't put my current ORM (Opf3) in the list but they decided to put my old one (OPF.NET) in the list... Big Smile

    I don't know if the .NET framework is really getting larger. It's more that we get more and more frameworks that build upon the .NET framework. I don't find that any bad because if these frameworks aren't present people would always claim that Microsoft is not building anything on top of .NET Wink

  • User profile image
    vesuvius

    W3bbo said:
    Three words: "Visual Studio Integration"

    Oh, and "free (as in freedom) for any work"

    Which cuts out a lot of those contenders.

    As for Linq-to-SQL (DLinq) vs. ADO.NET Entities: I don't believe they're directly competing. DLinq is a much simpler system that generates 1:1 entity classes and not much more, which makes it perfect for simple applications, whereas ADO.NET Entities provides the power needed for more complicated things, but overkill for simpler, RAD scenarios.

    On the plus side, this does mean an end to Typed Datasets. This can only be a good thing.
    In truth an MSDN subscription, and team foundation server are not necessarily free, and 9 times out of 10 they are the environments geared towards fully utilising such features.

    RAD does exist, but the demand for applications nowadays, are for them to be exposed over the internet. Presently I'm developing a client application, and need a rock solid data access layer so I can develop a Silverlight end in the future, exposing it to the Internet. I can then upgrade it to WPF in the future - need be. When you look at the advantages in this video, SQL compact can be used to store all your lookup tables. In a multi user applications, database hits are significantly reduced. Linq to SQL Compact is as yet (will it ever be) unsupported (the amount of hits I've had about this on my blog), so your disliked disconnected datasets make the best sense to use in such a scenario.

    I have had to take the decision and as yet Linq to SQL is full of bodges in order to make it work in such scenarios, which makes it unattractive. I'm sure the entity framework will correct this in future versions, but I need software that offers disconnected features today.

    I think you need to quantify what a simple application is? From notepad to SQL compact, the simple tools area is well catered for, so you need to look at the areas not catered for like REST'full services over the net etc. There is very little demand for simple programs nowadays.

  • User profile image
    vesuvius

    stun said:
    I agree that the .NET Framework is getting bigger.
    But I am pretty sure that Microsoft will guide its growth in a more gradual process.

    The Java J2EE world has so many choices (e.g., Struts, Java Server Faces, NHibernate, Ant, etc etc...) due to the Open Source efforts.
    This gives us, the developers, many choices to choose from instead of having to stick with what was given to us.


    The Entity Framework and MVC Framework are allowing us to use alternative approaches and methods to solve the problems we have.
    It all comes down to the developer's choice and vision and how comfortable he is with using what is available out there.


    In my opinion, as long as there are alternatives out there and different way of doing things, I think it is better for the ecosystem.
    Sure, it might get confusing to choose from for inexperienced people, but that is the whole reason why *basic* out-of-the-box functionality is enough to do many things.
    The developer just needs to decide on what would be the most effective way and picks up new technologies and learn them on his own.

    Just my 2c
    So choice is a good thing, and whether one uses Visual Basic or C# or whatever .NET language they prefer is irrelevant. Some people are comfortable with datasets, other prefer connecting to an ORM.

    I must agree with the thrust of this argument, mostly because of the ALT.NET practices creeping into the framework, so are likely to placate those that despise the previous .NET data access technologies.

    I just hope this new managed extensibility framework can omit duplication, because if you're learning WPF and WF you have to learn two different ways to do the same thing. This is where choice is bad, because you have people using 15 technologies that they chose (ORM example above) which does pretty much the same thing. In .NET, Microsoft Intermediate Language is the lowest common denominator, but this does not exist with ORM's, so you've got to ask what the intrinsic advantages are for choice here, and whether it's choice for choice's sake.

  • User profile image
    vesuvius

    PerfectPhase said:

    As others have said I don't see L2S and EF at odds, L2S is in effect direct binding to the DB schema, EF adds a lot more and is a lot more complex and I don't think will fully mature for a few more versions.  sometimes it's nice to have a simple framework that does overwhelm you on first use.  L2S is pretty much done and doesn't need to go any further, if it does then it starts treading on EF's turf.   Would be nice to have a option for L2S to migrate the model to EF.

    I think the other big thing is MS had to ship a DB LINQ provider when LINQ was released and there was no way EF was going to be ready.

    Another sign of things to come is the penertration of EF into other framework components, that's something we never saw with datasets.
    Well that is a key feature and advantage over datasets, the fact that you're not tied to a .NET shop. The REST stuff is fantastic as well but there will be times when finer granularity is required over the internet using SOAP. Again it boils down to using the right tools for the job.

    I have yet to see any full scale enterprise applications written top down with Linq to SQL though, as there are features that are glaringly missing (disconnected data access for one) and the Entity Framework is two days old and as far as I can see, not supportive of such scenarios yet.

    Saying Linq to SQL is pretty much done is saying that it was perfect when released! I'm not so sure?

  • User profile image
    vesuvius

    staceyw said:
    Not sure.  I was confused about the overlap at first, but now I see what they did.  They *delivered code with L2S a year ago.  EF is just out.  So they had to deliver something with first linq and not wait until EF was cooked.  Plus EF, as others said, is a different product with different goals.  It like saying they should not develop Word because they already have Notepad or visa-versa.
    I love analogies, and that is a good one. You can explain so much more with so little, and that much clearer. It would have been nicer if the pandemonium around the release of Linq had intimated that the entity framework was the way to go, and not offer Linq to SQL as a one size fits all solution  - n tier linq is one of the top posts in my blog.

    I have had my fingers burnt with Linq to SQL, so I'm afraid will wait till the EF is clearly mature, and offers feature parity with the technologies it replaces. It's one thing doing a few things really well like Linq to SQL, but then failing at other things, because the development team had to leave things out. I can't remember the last complete-ish release Microsoft released after .NET 2.0.

  • User profile image
    vesuvius

    Minh said:
    I think it's irrelavant how big .Net gets. Take .Net 2.0. I've given up the hope that .Net can be a general development platform (distributed over the net), simply because you can't tell people to download a 25 MB install. The opposite is true for Silverlight, of course.

    So, if the redistributable doesn't matter anyway, then it can grow as much as it needs to. At which point, size becomes choice, and the more choice, the better.
    If only someone had thought of the Client Application Framework back then, when it was just .NET 2.0. That 25 MB download would have been 8 MB. This has come about because of Silverlight. Microsoft have had to think small - the Silverlight plug in - and this is the by product.

    It is a direct consequence of their disproportionate concentration on ASP.NET.

  • User profile image
    vesuvius

    littleguru said:

    They didn't put my current ORM (Opf3) in the list but they decided to put my old one (OPF.NET) in the list... Big Smile

    I don't know if the .NET framework is really getting larger. It's more that we get more and more frameworks that build upon the .NET framework. I don't find that any bad because if these frameworks aren't present people would always claim that Microsoft is not building anything on top of .NET Wink

    Just out of interest, are you PMing on the Sync Framework team? Does that not include SQL Compact?

  • User profile image
    littleguru

    vesuvius said:
    littleguru said:
    *snip*
    Just out of interest, are you PMing on the Sync Framework team? Does that not include SQL Compact?
    We use it for the MetadataStore that comes with the Sync Framework but I don't know if there is a provider for it... At least I can't remember seeing a provider for the Sync Frameworkt hat works for the SQL Compact Edition; but I might be wrong since I'm fairly new to the team and everythign Smiley

  • User profile image
    vesuvius

    littleguru said:
    vesuvius said:
    *snip*
    We use it for the MetadataStore that comes with the Sync Framework but I don't know if there is a provider for it... At least I can't remember seeing a provider for the Sync Frameworkt hat works for the SQL Compact Edition; but I might be wrong since I'm fairly new to the team and everythign Smiley
    I'm just trying to figure out what the sync framework is?

     I recently watched this Visual Basic Vid about synchronising SQL Server and SQL compact. Is this a part of it and are you involved in some way with it? As a C# MVP (or former), I'm under the impression that this, like the dataset designer etc. is owned by the Visual Basic team (which is why most C#'ers dislike them - datasets that is)

  • User profile image
    PerfectPhase

    vesuvius said:
    PerfectPhase said:
    *snip*
    Well that is a key feature and advantage over datasets, the fact that you're not tied to a .NET shop. The REST stuff is fantastic as well but there will be times when finer granularity is required over the internet using SOAP. Again it boils down to using the right tools for the job.

    I have yet to see any full scale enterprise applications written top down with Linq to SQL though, as there are features that are glaringly missing (disconnected data access for one) and the Entity Framework is two days old and as far as I can see, not supportive of such scenarios yet.

    Saying Linq to SQL is pretty much done is saying that it was perfect when released! I'm not so sure?

    What I was saying about L2S being done was that it doesn't make any sense now to keep throwing more features at it when a more complete framework like EF is now in play.  Let L2S be the simple RAD version for directly connected client server database apps.  Let EF do all the heavy weight work required for disconnected systems.

  • User profile image
    littleguru

    vesuvius said:
    littleguru said:
    *snip*
    I'm just trying to figure out what the sync framework is?

     I recently watched this Visual Basic Vid about synchronising SQL Server and SQL compact. Is this a part of it and are you involved in some way with it? As a C# MVP (or former), I'm under the impression that this, like the dataset designer etc. is owned by the Visual Basic team (which is why most C#'ers dislike them - datasets that is)
    The Sync Framework is part of the SQL Server Group. We are not associated with the VB.NET team in any ways! The Sync Framework in it's core is build as an unmanaged component where the managed layer sits on top of it. You can use the framework from C/C++ or any managed language.

    This here is a short post about what the Sync Framework is and does. The idea is basically the following: you write providers for your endpoints (lets say one for your file system and one for Smugmug). Then you set both up (select a directory holding pictures on your file system and give a username, password and album to the Smugmug provider). Next you can synchronize the album with the pictures on disk and vice versa.

    You can even add a third provider or n smugmug or file system providers and they will synchronize the data.

    The framework, of course, provides also ways to deal with conflicts.

  • User profile image
    vesuvius

    littleguru said:
    vesuvius said:
    *snip*
    The Sync Framework is part of the SQL Server Group. We are not associated with the VB.NET team in any ways! The Sync Framework in it's core is build as an unmanaged component where the managed layer sits on top of it. You can use the framework from C/C++ or any managed language.

    This here is a short post about what the Sync Framework is and does. The idea is basically the following: you write providers for your endpoints (lets say one for your file system and one for Smugmug). Then you set both up (select a directory holding pictures on your file system and give a username, password and album to the Smugmug provider). Next you can synchronize the album with the pictures on disk and vice versa.

    You can even add a third provider or n smugmug or file system providers and they will synchronize the data.

    The framework, of course, provides also ways to deal with conflicts.
    That clears things up then. Basically, the sync stuff in .NET is another managed wrapper. Obviously the biggest thing at the moment is cloud computing, and LiveMesh. Does the sync framework sit beneath all of this as well and they add the ability to add devices etc. On you local machine to the cloud using it? If so, as some niners say, that is hawt!

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.