3 ms·
I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as l
by dommer 11y ago
I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible.
Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html
Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627 http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui...
[EDIT] Removed the unnecessary/unhelpful opening statement.
- untitaker_ 11y agoParticular things have to be decided upfront. You can't just add an app framework as an afterthought to your code.
- dommer 11y agoI'm unsure about that and I think it depends greatly on what is the goal. You can very easily do DI without Spring. (yes I know Spring is more than DI) As the project grows you can simple add Spring if brings 'real' value. You can defer the choice of data store very late in a project without hinder its progress. I'm not anti-framework/tooling, I just want to make sure it is required before I add it. Most, if not all, frameworks require some specific bootstrapping/configuration that is extra to the job at hand.
- inglor 11y agoJust because uncle Bob says something doesn't mean it's true. Frameworks and stacks provide templates for building CRUD apps. Building CRUD apps (read: database skins) isn't a big technological challenge most of the times anyway. So picking a stack that abstracts most of it for you could be a great help to only focus on the parts you care about. Not every project requires astronaut architecture and grand design. Half the internet runs perfectly fine without these considerations. Scaffolding a project through the tooling of a framework (tooling matters!) and having something up in a day instead of philosophical debates about your data is huge. Having something up in production super fast because you didn't stop to think about architecture is perfectly fine for 95% of software projects that are just CRUD.
- dommer 11y agoMy inclusion of these two reading resources were only meant as examples. The reader is still required to make their own mind up. I haven't suggested astronaut architecture; the question didn't indicate the size/scale/importance either. 50% of the internet runs perfectly fine without consideration...wow! Have you looked at all the source code yourself to make such a ridiculous conclusion. Tooling does matter, but I'm suggesting the point of focus to start with is the requirements.
- inglor 11y agoAs a data point, 20% of the internet runs WordPress [1], think these people spent a lot of time thinking about architecture. A lot of time the problem being solved is in fact simple enough and easy enough to solve without thinking about architecture, not everything is a hard problem - and there is nothing noble about solving things over and over. The point I was disagreeing with was "Pick stacks as late as possible". If you have a large project by all means do that, if you're just building a REST API in microservice architecture, or you're building a blog or something that's fairly simple to model - you're perfectly fine picking a framework you like first. [1] http://w3techs.com/technologies/overview/content_management/all/ http://w3techs.com/technologies/overview/content_management/...
- dommer 11y agoI'll skip the flame about WordPress developers as I don't know any, or, viewed their work. If you think building micro service architecture can be done without consideration I'm lost for words. The question–as I've been rightly reminded–was 'CRUD Web App in JVM'; furthermore, we now know that the domain part of the application is already done, so my comment is moot. That just leaves CRUD, Web, and JVM.
- Scarblac 11y agoHe did start with the use case -- "a simple CRUD app". That is sufficient to start looking for a framework, in my opinion. Cases where that is wrong aren't simple.
- 11y ago
- duiker101 11y agoYes/No, depends on many factors IMHO. Mostly on the person/team that needs to build/use it. We know nothing of OP's case so the best thing we can do is trying to answer his question instead of answering to go read some lengthy book. OP might be in a team that needs to develop an API for a product that will be deployed to millions of people(I doubt it) or could be someone that just wants to know what is the current fashion to develop a CRUD application while learning a new stack that is up to date. In the first case, you might want to learn more of the situation you are in and pick around that. In the second case, there is nothing wrong with just picking one and hacking away.
- dommer 11y agofair comment. I will add though, spring, or hibernate, or play, or [pick your framework here] will also require reading.
- dtech 11y agoI think "JVM Web app that does CRUD" is sufficiently narrow to consider that your use case, and pick a technology based on that use case.
- deleted 11y ago[deleted]
- networked 11y agoFor context, I already have a JVM application that handles the business domain. Adding a CRUD user interface (and, coincidentally, a database) is the next step I have in mind for its development. However, I didn't want to state those constraints in the OP because I wanted the answers to be broadly applicable.
- dommer 11y agoyou can look at this list of Java awesomeness. https://github.com/akullpp/awesome-java https://github.com/akullpp/awesome-java Or other awesome stuff at the parent project. https://github.com/sindresorhus/awesome https://github.com/sindresorhus/awesome
- hluska 11y agoThe OP listed the following requirements: "simple CRUD app" That is more than sufficient to pick a framework/database and start working. I'm not sure how many simple CRUD apps you have built, but the challenge tends to come when you put them in front of users who can't figure out the interface. Consequently, I'd argue to choose a framework quickly and get it in front of a user as fast as you can.