Frameworks, frameworks, frameworks.

Rocky Lhotka posts up an interesting thread rebutting some feedback from people about CSLA.NET. Reading through the post I can see that in a lot of cases people are comparing with EntLib.

I haven’t used CSLA.NET so I can’t really comment on that aspect, but I will say that anyone thinking of adopting any framework needs to consider this:

  1. How much leverage is the framework really going to give you?
  2. Can you already do 80% of what you need out of the box with .NET?
  3. Do you really need the other 20%?
  4. No really, do you need it?

Finally, I think that a lot of people when adopting frameworks seem to forget what the .NET framework has out of the box to allow you to build a lean mean application.

  • System.Diagnostics (for all your logging needs)
    • Trace.TraceInfo(…) is one of the most methods around.
  • System.Data (for all your data access needs)
    • I’ve been using System.Data.Linq lately and I love it.
  • System.Configuration
    • I can haz configuration data!

I’m tired of seeing simple applications made bloated simply because our “standard” is to use some random framework. Teams that have time to think about that stuff are probably building more than they need anyway.


5 thoughts on “Frameworks, frameworks, frameworks.

  1. Kevin Daly

    I’ve also been quite alarmed on a couple of occasions recently by people who’ve seemed completely lost in the absence of a framework and all but pleaded with me to point them at one…so I found myself having to resist the urge to ask “You *do* know how to, um, you know, program don’t you?”

  2. Jason Stangroome


    I’ve been using Strongly-Typed DataSets for all my data access and business logic but there are several aspects to them that are awkward to work with. I’ve since been searching for an alternative approach to write collections of business objects that can do binding and validation.

    I’ve started without a 3rd party framework but as I refactor code into base classes my project starts to resemble many of the existing framework solutions. I can’t help but feel I should have just made use of someone elses work.

    I agree that System.Diagnostics and System.Configuration are ample for most needs and EntLib seems overkill but in a pre-Linq environment is System.Data really all that is required?


  3. Mitch Denny Post author

    Hi Jason,

    Its a very seductive argument. But in the end you need to ask yourself, will the framework give you the leverage that you want? There is a non-zero cost associated with adopting (and then maintaining) someone elses framework.

    In my experience this is higher than the cost of developing a minimal implementation for each project which often has less code and performs better. Note that I’m not arguing for doing everything the long way round, I’m unlikely do do much custom control development in any project for example – but when it comes to data access, the .NET Framework is pretty good.

    Even DataSets in ADO.NET 2.0 with Table Adapters are quite nice, although I prefer LINQ because I am more of an objects guy really.

  4. Pingback: PaulStovell.NET » Mitch on Frameworks, Frameworks, Frameworks

  5. Pingback: Alex in a nutshell » Do we need frameworks?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s