SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Enthusiast graphical_force's Avatar
    Join Date
    Sep 2008
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    frameworks: Something I should be using?

    Hi, I have been looking at different php frameworks but this is more of a general developing issue. I was wondering what the current opinion on frameworks (no matter the language) in general are? Is this something that people embrace to make there jobs easier? I have read this thread but it is a little old so I thought I would get a more recent opinion on it.

  2. #2
    SitePoint Evangelist
    Join Date
    Aug 2007
    Posts
    566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I, for one, never crossed a framework I was happy with.
    I always ended up ditching it and going straight for the mechanics.
    I've worked for so long without framework that re-learning an abstracted method is just a strain.

    And I've often reached a side of the framework that made my work harder because what I wanted/needed to do was against the basic of the framework.

    But my greater grief is about orm.
    I'm a DBA, so sql and set based operation comes naturally to my mind.
    But orm syntax is just plain ugly, and I simply cannot stand it.

    I've been burned to the second degree the day I wrote this:
    http://www.webalis.com/2008/05/pytho...uck-that-much/

    But hey, I never said I was being fair.
    :-)

  3. #3
    SitePoint Enthusiast graphical_force's Avatar
    Join Date
    Sep 2008
    Posts
    93
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are frameworks expected to be used by companies or are they viewed as it's up to the developer to use? I am sure that it is true in some instances, I just want to see what others think about this.

    Thanks for the response!

  4. #4
    ALT.NET - because we need it silver trophybronze trophy dhtmlgod's Avatar
    Join Date
    Jul 2001
    Location
    Scotland
    Posts
    4,836
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wouldn't develop without my application framework. Mine is Castle Windsor (.NET) with NHibernate. At it's core, Castle Windsor is an Inversion of Control container but also supplies a load of other facilities to aid development.

    I wouldn't work without it, and I wouldn't recommend working without one. Why not?

    Productivity.

    I can get things done faster with a framework. By sticking with "convention over configuration" your framework should not intermingle with your core domain code and allow you to concetrate on your core domain without worring about framework concerns. If framework code does infect your core code, which is what it sounds like tripy, then your doing it wrong or your framework sucks. If you develop with proper OOP, then using most decent frameworks (on the .NET platform anyway) should be fairly transparent and frictionless, if it's not, then move to a different framework.

    The most important feature of an application framework is that it should allow for Infrastructure Ignorance. Your core application should not be aware of your framework, it should transparently stitch everything together at runtime and stay out of the way.

    A good framework should comply to the "Open/Close Principle" and allow for easy extension. My application framework allows for this, and I can quuickly extend it without changing any code of the framework or compromising Infrastructure Ignorance. This is achieved in a number of ways, Dependency Injection, AOP, Component Forwarding.

    ORMs are the same, the core feature that makes an ORM good is Persistence Ignorance. Your domain model should not know or care how it is persisted (See .NETs Entity Framework for an epic failure for this). This aids testability (if you practice TDD, which you should be!) and increases productivty. If your a developer and your writing raw SQL, then your stealing from your employer. Data access and persistence is a problem that has been solved.

  5. #5
    SitePoint Evangelist
    Join Date
    Aug 2007
    Posts
    566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If framework code does infect your core code, which is what it sounds like tripy, then your doing it wrong or your framework sucks. If you develop with proper OOP, then using most decent frameworks (on the .NET platform anyway) should be fairly transparent and frictionless, if it's not, then move to a different framework.
    I have tried many framework. Be them php, javascript or python, and I never have found one I can say I felt at ease with.
    I always ended up hitting a wall, and usually the answer of the community/support was "you cannot do it that way" or "it's not supported yet".
    I have developed what could be considered as a "light" framework over the years, and with it, I can be productive.
    At the same time, I'm so used to, for example, the javascript DOM, than the limitation a tool like prototype.js brings are more limiting than time freeing.
    Because even if I know how to work it in pure, raw DOM scripting, I have to accomodate the limitations or conventions of the framework.
    It has to come to a balance, and the balance was clearly not in favor of the frameworks I tried in the past.

    Maybe my needs where different too.
    I never have done something like a blog, a dating or gallery site.
    The project I was involved with where often related to web services, and creating API's to allow either SOAP or XML-RPC access to them.
    And performances where always the first priority.
    Portability was seen as the devil himslef, and productivity was not the most encuraged point. Quality of the code and speed/reactivity of the services where.

    The most important feature of an application framework is that it should allow for Infrastructure Ignorance. Your core application should not be aware of your framework, it should transparently stitch everything together at runtime and stay out of the way.
    I am particularly defiant about that.
    I am now working as DBA, and was a web dev before.
    I never saw a project change of platform in the course of it's development, and I seriously consider that if you have to change your environment, then someone has seriously screwed his job.

  6. #6
    ALT.NET - because we need it silver trophybronze trophy dhtmlgod's Avatar
    Join Date
    Jul 2001
    Location
    Scotland
    Posts
    4,836
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I never saw a project change of platform in the course of it's development, and I seriously consider that if you have to change your environment, then someone has seriously screwed his job.
    This is a common misconception of what is meant by Infrastructure Ignorance. It's not about platform, but developing an application with properly seperated concerns that you can test in isolation without worring about the infrastructure or how dependencies are going to be resolved at runtime.

    For example, we're finishing off an application that communicates with a 3rd party SOAP web service, pulling down a lot of data (100GB+) and performing advanced filtered/dispatch of the data on a nightly basis. To accomodate for this, and to allow for adding more filters without editing the original codebase, we fully use our Application Famework. We are at the point where we can simply drop in a new assembly and it will be automatically included. These assemblies have zero knowledge of how they are included in the application as they comply with Infrastructure Ignorance. This means they are extremely easy to run in isolation, which allows for easy testability and small tightly focused classes.

    However, this isn't something we planned from day one. Using iteration based development with TDD, we slowly evolved the application in this direction as different requirements came in. We had extreme flexibility because of our Application Framework did not intrude on our core business logic and we can make large sweeping refactorings with confidence whenever we want.

    An Application Framework that complies to OO Principles will not impare code quality, infact it would enhance it. A good Application Framework will lead you down the path of using well known patterns and help improve the quality of the code and team communication

  7. #7
    SitePoint Evangelist
    Join Date
    Aug 2007
    Posts
    566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is a common misconception of what is meant by Infrastructure Ignorance.
    Ok, I understand it better now.
    I never worked with .NET, as I mainly am involved in the unix/bsd world, but it's true that if I heard something recurrent about .net, it's that it is well thought.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •