Even full stack has its problems. It's that whole "generalist" vs "specialist" argument - sure you can do a bit of everything, but in doing that, can you actually devote yourself to becoming a master in something? Pretty hard to do. It's yet another flaw in Agile I think. And that said, that's what I am, a full-stack developer (although I am also quite strong in SQL Server, but never really felt inclined to follow that path more deeply.)
I understand the point of people who have devoted their lives to data, and having worked in a few large corporates, I can say that the data point of view and stored procs have merit, in that politically it is much easier to deliver patches via transactional database update scripts than it is to redeploy a monolithic application. Being data centric can have its limitations once the applications get significant though, as a database itself is one huge brittle API, and when the contract changes and you have to change your data structure, it can effect everything. The microservices approach is supposed to get around this somewhat, as breaking down the monolith and compartmentalising specific purpose chunks of functionality (which is the high cohesion, low coupling life pattern again) does give you the ability to deploy those individual slivers independently of each other if you need to. Great when it works. Microservices doesn't actually care where you store your data. Each microservice can store the data wherever the coders decide, and that might not be a relational database at all. All you do is provide the interface to the "consumer" and provide a contractual outcome. Microservices follows more of a domain driven design approach, which, when done properly, can provide a more flexible, small 'a' agile outcome, and uncover ideas that can lead to innovative ideas that provide a strategic advantage, that would otherwise not have been identified in a data centric environment. And within ddd it is done by sticking to single-directional relationships between POCO entities by focusing on real world problems. So you can argue one way or the other, but I see benefits both ways depending on the circumstances. On Fri, Sep 16, 2016 at 11:58 AM, Andrew Tobin <and...@grrargh.com> wrote: > Document/Object DBs are kind of the solution for that, however, they still > need to be managed. > > Grow a beard and become "full-stack". > > On Fri, Sep 16, 2016 at 11:56 AM, Greg Keogh <gfke...@gmail.com> wrote: > >> The people who think that ORMs are a good idea have a code-centric view >>> of the world. >>> >> >> Stored procs! >> >> Here's the black hole of the argument. To me it's a simple reductionist >> problem... Clean-shaven code-centric people write real-world apps. Beardy >> DBAs design databases. Coders need databases. Databases are unlikely to >> have a structure that suits coders. What can bridge the "impedance" gap? >> Something has to. >> >> It doesn't matter how much you like stored procs, you still have to get >> stuff in and out of them across the gap to the coder's classes. How do >> procs help? Are you proposing that more business logic be moved into procs? >> If so, that way lies madness, as you can't easily integrate proc code into >> source control, testing, versioning, builds, etc. I've seen whole apps >> written in T-SQL, and it's quite frightening. >> >> Coders need ORMs, heavy or light. I've only used 2 this century, but they >> simplify and reduce code by a staggering amount. The benefits far outweigh >> the deficits. >> >> I was just discussing this with a colleague and we have made a casual >> pact that in future apps we will try to meet more halfway across the "gap". >> He will write procs that aggregate and deep load joined data for complex >> queries, then my code on the ORM side will query what the proc assembles. >> We haven't worked out the details of this plan, but I think it lets each >> part do what they are best at. The procs will assemble and shred data out >> of tables and the code will work with business objects. >> >> *Greg* >> > >
