37

When developing a system or application that you plan to use with a certain framework, is it best practice to design the system without the framework in mind, or is it better to design the system with the mindset "well the framework would have an easier time with this".

  • 4
    What kind of framework are you talking about? Do you mean some niche business-specific framework which is designed to solve very domain-specific problems for a particular industry? (e.g. medical, nuclear, defence, aviation, etc.). Or are you talking about general-purpose frameworks designed to solve technical problems? – Ben Cottrell Apr 12 '17 at 10:10
  • 1
    general-purpose frameworks designed to solve technical problems – Robert Pounder Apr 12 '17 at 10:19
  • 2
    Small scale for lack of time (I am in work, may elaborate later): I'm writing a system that generates emails based of designs. - If I were writing this in Laravel I would probably go about using their templating engine "blade" for designing the emails, which would make the designing of the system a lot simpler in terms of flow. However I would have to go about writing a templating engine if I was doing it vanilla PHP, or finding another suitable alternative templating system. It would add to the design process, which the question is referring too. – Robert Pounder Apr 12 '17 at 14:29
  • 3
    This question is going to generate a bunch of vastly different answers because both "framework" and "design" are words overloaded with multiple meanings in our industry. Furthermore, even for a single definition of framework as "general-purpose frameworks designed to solve technical problems", it's going to depend on the specific framework - some frameworks are more opinionated than others. – stannius Apr 12 '17 at 15:19
  • 1
    It would be too bad to be hit by a bus while lost in thought trying to design a wheeled public transit vehicle. – user251748 Jun 2 '17 at 18:02
51

Your design should meet the clients needs as closely as they can. Remember that design includes little things like:

  • User experience
  • Functionality
  • How pieces of your application communicate (either with itself or external entities)

None of these things should be dictated by the framework. If it's clear that you will be fighting your framework to accomplish these goals, then you choose a new framework that will help you accomplish those goals before you start writing code.

Once you've chosen an appropriate toolset (the framework is a tool), then I recommend using the tools the way they are designed to be used. The further you deviate from the framework design the more you increase the learning curve for your team, and the greater chance of something going wrong.

In Short

  • Design for your users
  • Pick the appropriate tools to accomplish your design
  • Use your tools the way they are designed to be used

Further Thoughts:

After 20+ years of software engineering, and using several frameworks, I've learned a couple lessons. All frameworks are a double edged sword: they both constrain and enable. The issue with deciding your framework before you look at the big 3 I mentioned above is that you might be compromising a good user experience for a mediocre (at best) one. Or you might be forced to deviate from the frameworks design to accomplish some specific functionality.

  • 3
    Then you need to do some negotiations with the client. Explain what you can and cannot do with the constraints they have imposed. Propose how that can change if you choose X framework. They may not be willing to change and are willing to live with a degraded experience. Or they may decide that you know what you are doing and trust you. That depends on the client. At the end of the day, you manage their expectations. – Berin Loritsch Apr 12 '17 at 12:33
  • 4
    There seems to be some confusion between different levels of design here: system design and detailed design. To me, this question was asking about the detailed design (the implementation method) rather than the system (interfaces, concurrency, data volume, user interface, user type). – Gusdor Apr 12 '17 at 13:03
  • 2
    If the question turns around "technical design", then language and OS may have some inferences in the design. But still, design is not implementation. If you are thinking in Frameworks capabilities, It's not design, It's implentation. If you base your design decitions on the framework strenghts, prepare yourself for suffering its weakness. And when weakness meet requirements, you have a huge problem. The largest companies didn't build theirown frameworks for pleasure. – Laiv Apr 12 '17 at 20:02
  • 1
    @Laiv Great comment! Really, it is "some and some". A nailgun and a screwgun both can fasten stuff, one is more reversible than the other and also works slower and is more complex. Every choice people make is unavoidably a tradeoff. You pays your money and you takes your chances. – user251748 Apr 13 '17 at 0:19
  • 1
    @RobertPounder, It is a tool who's appropriateness for a solution needs to be decided while designing the system. I understand how frameworks can influence design, but they shouldn't dictate it. – Berin Loritsch May 10 '17 at 11:47
27

Frameworks naturally influence the design of specific modules and sub-systems (such as a GUI front-end). As the other answer mentioned, you will have a difficult time if you find yourself fighting against your chosen framework(s).

More broadly however, you should avoid letting any single framework or technology dictate or drive the "big picture" of your overall system architecture. Most general-purpose application frameworks don't encourage this, so if you find yourself writing your entire system around one framework then you're probably doing something the authors of that framework didn't intend.

You will likely use many different frameworks to solve different problems; as your system becomes more complex you need to be careful not to build The Big Ball Of Mud. Where possible, keep your system modular and loosely coupled. Some frameworks might be better kept behind abstractions by writing wrappers and adapters which 'hide' the Framework-specific workflows away from other components. GUI toolkits tend to only serve front-end GUI functionality, so those GUI modules should be kept away from the rest of the system.

General-purpose frameworks (such as UI frameworks, data layer frameworks, etc.) don't exist to prescribe the complete architecture of your system - at most they might prescribe the design of a component or module; for example, some GUI technologies are geared towards particular MV* patterns.

The overall architecture of your system should be primarily driven by your business requirements. You may find yourself leaning heavily on a particular tool (for example, a messaging middleware tool, or an ORM framework) in order to tie everything together, but if you've encapsulated the framework in an abstraction such as a 'service' class you're less likely to find yourself being constrained by that framework when you encounter its limitations.

Try to keep the following in mind for your big-picture design:

  • Sometimes it seems some framework authors don't mind at all having their users writing application code tighty coupled with the framework. – COME FROM Apr 12 '17 at 12:24
  • 2
    @COMEFROM - Tightly coupling your code to a framework would be encouraged by the developers because they assume you chose their framework to solve the same problems they designed it for in the first place. – JeffO Apr 12 '17 at 12:34
  • You went a little off-subject, going from design principles to coding principles, but I get the jist of what your saying, what if the business requirement is that a certain framework be used? (think company out-sourcing and the in-house devs only know one language) I think I should of made this clearer in the original post. – Robert Pounder Apr 12 '17 at 12:46
  • 1
    @RobertPounder The real point I'd been trying to get at (perhaps not very well) is that there is sometimes a tendency for people to use particular frameworks as a 'grounding' for their entire application - which inevitably leads to business logic and other unrelated code being inappropriately fused to that framework - e.g. business logic being coupled with UI controls just because it was quick'n'easy at the time. It's very easy to do that, so it's something to be wary of – Ben Cottrell Apr 12 '17 at 15:29
  • 2
    I must disagree with @nocomprende here; not all future requirements can be predicted, but sometimes systems are rewritten simply because the previous software is too difficult to extend / maintain. – SeldomNeedy Apr 13 '17 at 4:04
7

Yes, you should stick as closely as possible to what the framework "tells" you to do.

The reason is simply that the closer you stick to the frameworks way of "thinking", the easier you will be able to talk to other developers about your problems/ideas that also use that framework.

You increase interoperability and ease of use for other people that use it later, you will understand and incorporate tutorials or common solutions better if you stick to the underlying philosophy of whatever you're using.

The only good reason I can think of why you would "break" the framework is that you absolutely need something it cannot provide given its "default" configuration/application of principles. But then, it might not be the right framework to begin with.

Basically, this can applied to other decisions as well. You should use the language you're using as closely as it's intended to be used, because it makes things easier if you're talking the same language as everyone else.

  • May be you should review your answer due to question's changes. Your answer actually doesn't answer the OP's question. – Laiv Apr 12 '17 at 11:44
  • 1
    @Laiv I don't see how it doesn't answer the question, albeit it might not match your opinion on the topic, it's still an answer. You are most welcome to write your own answer to display the conflicting nature of the topic in question. – Florian Peschka Apr 12 '17 at 11:51
  • Excuse me if I didn't explain well myself. I'm not as fluent in english as I would like to be. I just wanted to say that, IMO, the question and your answer speak about different things. If you think they don't, It's ok. I won't argue that. That's it. – Laiv Apr 12 '17 at 12:14
  • 1
    This is absolutely it. It is similar to how Domain-Specific Languages and similar ideas work. Your products are shaped by the tool (Framework) not the other way around. The Framework "wins". If you can't marry it, then choose a different one. (Hint: there is no ideal Framework. Just sayin'.) – user251748 Apr 12 '17 at 18:02
  • 1
    Your design should influence which framework you choose (if any!), not the other way round. – RubberDuck Apr 14 '17 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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