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".
Your design should meet the clients needs as closely as they can. Remember that design includes little things like:
- User experience
- 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.
- Design for your users
- Pick the appropriate tools to accomplish your design
- Use your tools the way they are designed to be used
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.
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:
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.