2

I am very puzzled with the obsession that many people seem to have with using Microsoft frameworks. I have seen several tutorials and projects (both open and closed source) that seem to utilize all of the additional .NET framework libraries and code when they are not really needed. To be clear, I am not talking about classes in System or anything like that, but rather full blown frameworks like ASP.NET Identity (and former iterations), OWIN, Entity Framework, MVC framework, etc.

On stuff that is 100+ pages, I see things like Entity Framework / ASP.NET Identity that make me cringe because of the overhead those libraries introduce into your code and database when it is just so much easier to create your own clean and flexible solutions that don't have bloat in them. I laugh at OWIN actually being used by any serious business application; why would you use a social media login to anything that is supposed to be even remotely secure? These frameworks can only be useful for small (i.e. 3-5 pages) applications that are not really important or critical to businesses. I can hardly think of major software companies or business using these frameworks in their enterprise software (probably just the MVC framework because of the Razor/view engine components).

What is the point of using these frameworks when they just introduce bloat, complexity, and over engineered code into projects? I could be missing something, but if I takes a few days to write a full database ORM structure and login logic using default classes that is lighter, faster, and more flexible versus using Microsoft frameworks why not? It seems that things like Entity and Identity would just introduce complexity and over engineering into problems that very easily solved with some simple analysis, foresight, and design pattern implementation. Do any of you actually use these frameworks in your own projects or enterprise level projects?

EDIT:

I wanted to slightly clarify myself for any future readers. I am not saying "rewrite all of Entity/OWIN/Identity (or X framework)", but rather think if you really need all of the additional code / dependencies such frameworks introduce. If you have 100+ pages that all interact with X framework (whether it be Entity or whatever) think about how much dependency and coupling you have. If you use a 3rd party library (e.g. HTML/Markup controls, ORM structure, CSS/JS framework, etc.) you will know what I mean when you have to update to a major version change or a different vendor. Even the best decoupling abstraction cannot save you sometimes.

  • 6
    The ORM structure you can write just in a few days - will it also tested and fully documented? If this is the case, you have superhuman abilities. – JacquesB Sep 3 '17 at 10:29
  • 4
    What issue do you have with OWIN? Most of that stuff (e.g. the HttpListener and the request pipeline) is all hidden away in the depths of ASP.NET so that you don't need to write your own HttpListener or handle requests for yourself. You can get a whole web service up and running in just a couple of minutes if you follow the "getting started" tutorials on asp.net - There's no way you could write all of your web service framework in less time than it takes to create a new visual studio project. – Ben Cottrell Sep 3 '17 at 11:09
  • @BenCottrell I am not saying to rewrite OWIN (by all means use it, IF your project ACTUALLY needs it) or anything similar, but rather don't throw it into every and any project because it's a .NET Framework. It is probably not needed in the large majority. From another point of view, it is good to know how it all works in case you (general sense) need to know how to write a similar component of it, but again use it if you actually need to. My point was that developers don't (or at least seem not to) think about what they are adding into projects in terms of overall total code / dependencies. – B1313 Sep 6 '17 at 2:46
  • 1
    @BerinLoritsch OWIN has nothing to do with JWT or authentication - it just provides the HTTP request handling and URL schemes - see owin.org/html/spec/owin-1.0.html - my point is that OWIN is the de-facto choice for .NET when implementing any kind of RESTful API, even just a console app (without ASP.NET or any of the other frameworks which are often associated with it). The question says "I laugh at OWIN actually being used by any serious business application" but I cannot think there's really any better way to write a RESTful service using .NET without reinventing the wheel. – Ben Cottrell Sep 6 '17 at 18:25
  • 1
    @BenCottrell, OK. Perhaps I conflated Identity Framework, which is OWIN based with OWIN itself. Identify Framework is something that I wish I could separate more easily. – Berin Loritsch Sep 6 '17 at 18:55
25

When you start a project and have a particular need, you have a choice:

  • Either you implement your own solution from scratch,

  • Or you use an existent library or framework.

When implementing your own solution, you introduce several risks:

  • The needs may evolve, requiring you to constantly write more and more code. Ultimately, the code you've originally written was never expected to be used in a specific way, and needs either a lot of refactoring or a plain rewrite.

    Popular libraries and frameworks are designed in a way to cover much more needs than you have when you just start a project, which makes them look bloated at the beginning. However, as the requirements change, those libraries show their use by making you adapt their usage with ease, when they are designed well (and many Microsoft's frameworks are designed well).

  • Any new person who joins the project won't be familiar with your implementation. This makes it unnecessarily complex for the newcomers to start working on your code.

    With popular libraries and frameworks, you don't have this problem. Either the new developer already knows the technology, or she doesn't, in which case, she has at her disposition a lot of in-depth, well-written documentation, a large set of Q&A on StackOverflow, training videos, etc. Developers themselves are usually more inclined to learn a popular technology than to spend a month trying to grasp YourMagnificentORM which, being proprietary, undocumented and poorly written, wouldn't give them any benefit when mentioned on a CV despite all its obvious qualities.

When using an existent library or framework, you introduce different risks:

  • The needs may evolve, and the library may not fit the new needs. This is especially important when the library is proprietary or when you're not inclined to contribute to an open source library.

  • The library/framework itself may lose its popularity (example: Silverlight) or the developers of the library may decide to take a course that doesn't fit your needs.

Both of those risks can be mitigated by a proper architecture where third-party code is abstracted from your business code.

seem to utilize all of the additional .NET framework libraries and code when they are not really needed [...] I am [...] talking about [...] full blown frameworks like ASP.NET Identity (and former iterations), OWIN, Entity Framework, MVC framework, etc.

What do you suggest to use instead?

If you want to implement OAuth authentication, you might re-implement OAuth protocol, although I'm not sure that spending a few months on that will really benefit your employer. Or you may just use the high quality code Microsoft developers provide you for free, and spend your time implementing actual features.

Owin gives you the ability to run your application outside IIS, given that the cost of using Owin in terms of code complexity is close to zero. If you are absolutely sure you will never ever host your application on anything other than IIS, and your team is unfamiliar with Owin and is not willing to learn it, there is indeed no reason to use it. Few teams are in this situation.

Entity Framework gives the ability to use a database to developers who are unfamiliar with SQL and databases in general. If you do have a skillful DBA in your team and if every member of the team has no issue writing SQL queries by hand, you don't need Entity Framework. Few teams are in this situation.

ASP.NET MVC makes it possible to structure your code using MVC architecture. Most developers find it superior to the architecture used by ASP.NET, leading to less code, less coupling, and proper abstractions. You get all those benefits for free (in terms of runtime performance), so the only reason not to do it is when you have a team of developers who absolutely love ASP.NET or when you need to maintain a legacy project which uses ASP.NET.

I laugh at OWIN actually being used by any serious business application; why would you use a social media login to anything that is supposed to be even remotely secure? These frameworks can only be useful for small (i.e. 3-5 pages) applications that are not really important or critical to businesses.

Owin has nothing to do with OAuth login.

Aside that, StackExchange family uses OAuth authentication, and it also uses ASP.NET MVC. Do you characterize those sites as “small 3-5 pages applications that are not really important or critical to businesses”?

What is the point of using these frameworks when they just introduce bloat, complexity, and over engineered code into projects?

The goal is exactly that: to reduce bloat, complexity and over-engineered code, by ensuring all the complex stuff is within those tested, reviewed libraries, and not your project. This is the code you don't have to read, maintain, document, review and test.

I could be missing something, but if I takes a few days to write a full database ORM structure and login logic using default classes that is lighter, faster, and more flexible versus using Microsoft frameworks why not?

Even properly documenting a basic ORM requires at least few months. A weekend ORM project may be fun to write at home, but I would hope you won't decide to use one in the projects which are “really important and critical to businesses.”

Do any of you actually use these frameworks in your own projects or enterprise level projects?

I work for one of the three largest European banks. We use OAuth to consistently provide SSO for every product. We use Owin, because most of the projects are hosted outside IIS. There are a lot of other Microsoft's libraries being used, which allows us to keep the code clean and maintainable, and focus on the features, instead of technical stuff such as the internals of WebSockets, REST or WebHooks. By spending a few hours or days learning how to use an existent library, we save a lot of time and money if we were writing all this stuff from scratch, and then constantly maintaining it. This is how businesses work.

You are, however, absolutely right when you talk about the feeling that simple projects are bloated. It is so easy to add a new package to a project, that many small projects tend to include the libraries they don't even use or at least don't need at their scale. Take CSS and JavaScript bundling and minification. For a starter project, there is little use to have one, but many tutorials present it as a default choice, transforming the whole system from opt-in to opt-out.

While those libraries rarely present a performance impact, they do however make the code more complex than it has to be. The same problem, by the way, exists in other communities; for instance, many Node.js apps I've seen tend to have way too much dependencies.

In .NET world, the culprit is not only the ease of adding libraries to a project, but also the fact that Microsoft promotes its ecosystem as something where you get "all the features you need," even if you don't necessarily need them.

  • +1 to this answer. There's just one point to make here: These libraries make everything harder to a newcomer. But most of them are just "fire and forget" types of libraries, where once you're used to work with them, they just work, and you never get back to them again. My point is, you have better long-time productivity over a steeper learning curve at beginning. – Machado Sep 4 '17 at 13:47
  • I applaud your answer for being VERY thorough and VERY detailed. While, I do have differing opinions in some areas (i.e. StackOverflow not being critical to outside businesses and there is only so much abstraction to do to a 3rd party package (i.e. Entity, NuGet Pkgs., etc.) that can ease coupling from your app (it still is a pain to switch)), you provided the best insight into several points. I am selecting your answer. I wish to change one point: while I think the ASP.NET MVC framework is ok (i.e. take it or leave it), I do not think it was my best choice for an example of a bad framework. – B1313 Sep 6 '17 at 2:36
  • P.S. A funny line I heard: ORM = those who can't code SQL. -- I always thought SQL was rather simple and easy to learn if someone has a free afternoon or day...guess it's more rare than I thought. – B1313 Sep 6 '17 at 2:39
  • @B1313, I don't understand why some developers don't like SQL as well. But I understand the desire to decouple entirely an application from a specific RDBMS. Maybe in a world where everything is big data, hadoop, etc there's no place for SQL. Who knows ? – Machado Sep 6 '17 at 8:31
  • 3
    @B1313: in a free afternoon, you get a basic understanding of SQL queries. It takes much more time to understand normalization forms, execution plans, good and bad ways to use indexes, etc. And it appears that in terms of performance, ORMs usually outperform those of the programmers who have only basic knowledge of SQL and databases. – Arseni Mourzenko Sep 6 '17 at 11:27
6

Yes, most places I've worked at use some of those libraries.

It is tempting to see them as bloat, I for one dislike Entity Framework and tend to 'hand crank' my repositories.

But, in fact the Microsoft libraries are very well written and are often complicated because they handle stuff you haven't thought of, or don't need yet.

This is especially true of anything security related.

Of course the other factor is time saving. Why spend time writing something you can have for free?

Also, it gives conformity across industry which makes hiring easier. I can find 100 devs who know Entity Framework but only 1 who is clever enough to understand the genius of Ewan Framework v9000

  • Thanks for your answer Ewan. Actually, I completely agree with security components (i.e. hashing and encryption algo's) but those are all in the default System Crypto library which is lighter than other packages. However, in response to the having something for free and just using it, let me pose this question...what happens when that framework drops off / gets discontinued? Having the underlying knowledge of how to write those kinds of frameworks is vastly useful even if you may not "roll your own". i.e. Knowing how to make the Ewan Framework v9000 is more useful than not at least knowing. – B1313 Sep 6 '17 at 2:22
  • 2
    well The MS libraries are supported for a very long time. – Ewan Sep 6 '17 at 8:17
5

The point of using frameworks compared to hand-rolled solutions is to save work and to reduce risk. A hand rolled custom solution might be more focused and have "less bloat" compared to a generic framework, but it will also:

  • Have more bugs - which only you can fix
  • Have worse documentation, no books or tutorial etc.
  • You cannot google for solutions to common problems.
  • You cannot hire people who already knows the framework, and it will be more difficult to hire competent developers.
  • Developers will be reluctant to invest too much time to learn you amazing framework, because the investment will not help them in the future.
  • If you leave the company or get hit by a bus, the business will be destroyed and you boss will be fired.
  • Your answer could be vastly improved by removing the editorializing and opinionated remarks. Oh and in response to your comment, I am not sure why it takes a month to document any code especially a small framework. My colleagues actually agreed with me on having less M$ software generally means less bloatware / broken code w/ updates. P.S. My framework has been working fine for approx. 2.5 years now (in production) and I can teach it to someone in an hour...try doing that with Entity or Identity...oh yeah, you need "books, or tutorial[s]" for those. – B1313 Sep 6 '17 at 2:17
  • 3
    @B1313: I don't dispute your particular framework is amazing, bug-free, documented and easy to learn. But you ask the question in general, and most teams consist of average developers (by definition) and does not have a "ninja rockstar" developer like you. And from a management perspective, over-reliance on a single elite developer is a major risk. – JacquesB Sep 6 '17 at 7:51
2
+500

Like most things in life generally and software development in particular it is a trade off. Lots of stuff you don't need and don't understand (or even why it is there) gets included in even the smallest of projects as the price of having standard things done properly and there being a large community of developers that is familiar with the environment and framework and how to work within it.

At least, on the basis of its record to date, we can trust Microsoft to support their frameworks and development tools for a long time to come and, so far as possible, to retain backward compatibility. That is unlike some other well known IT companies that introduce products, encourage us to use them, then drop them completely after only a few years.

protected by gnat Jan 29 '18 at 13:12

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.