Overarchitected Projects

[Jaws]

I'm working on a similar project, many layers on the back and front end (Typescript "single page app" that doesn't really need to be). I need to make updates to 7+ files every time I want to add a page into the UI due to how the routing is set up client side. Progress has been slow to say the least.

The trouble navigating the code is the way most of the files and classes have very similar names depending on what representation of the entity they relate too. I use resharper to navigate all of this, however I've needed to put more thought into how to quickly track down a file with the "ctrl-t" find type dialog. On a reasonably sized system you can get away with just keying in the initials of the type name you're looking for but now I find using the initials of the entity + start keying in the more specific representation like 'mlp cont' would find me MultiLayeredProjectController the easiest.

[Hobosapien]

Don't remind me about unnecessary layers.

Another project I've inherited that is even older than the EF based one is the typical 3 tier web app, but the middle tier is a web service built from dozens of 'business classes' mostly doing nothing significant but passing request/response DTOs through layer after layer.

On top of that they got into such a mess with the spaghetti code they copy/pasted loads of business logic across classes to avoid circular references or to quickly resolve transaction issues. Depending on the mood I'm in when I have to delve into that CRUD I either feel like or

On the plus side as each web method on the service is a distinct starting point I've been able to replace the code with a simple two layer Dapper based alternative as I go along as there are existing stored procs used for all the data access.

Though I have come unstuck on occasion when trying to clean up the code only to find there are business processes in place to work around some of the code bugs. So I can easily find myself back at if the bug fix is 'out of scope' for the project.

If I'm supposed to be a code monkey they could at least throw me a from time to time.

[Gumbo Robot]

Don't remind me about unnecessary layers.

Another project I've inherited that is even older than the EF based one is the typical 3 tier web app, but the middle tier is a web service built from dozens of 'business classes' mostly doing nothing significant but passing request/response DTOs through layer after layer.

On top of that they got into such a mess with the spaghetti code they copy/pasted loads of business logic across classes to avoid circular references or to quickly resolve transaction issues. Depending on the mood I'm in when I have to delve into that CRUD I either feel like or

On the plus side as each web method on the service is a distinct starting point I've been able to replace the code with a simple two layer Dapper based alternative as I go along as there are existing stored procs used for all the data access.

Though I have come unstuck on occasion when trying to clean up the code only to find there are business processes in place to work around some of the code bugs. So I can easily find myself back at if the bug fix is 'out of scope' for the project.

If I'm supposed to be a code monkey they could at least throw me a from time to time.

Exactly what's happening here.

Everything gets passed between 6 levels of dtos because somebody de ided it would be a good thing to have a domain driven design so we have a ui ,application, domain, service, infrastructure and data access layers. So, as you can imagine, just adding a new field to a request object takes frikkin' hours because I have to identify and update all the correct dtos, add mappings for each one and, worse still, when I inevitably miss one I have to go through the needle in haystack job of finding the missing mapping/dto

I genuinely cannot see the point in all thii....

[Hobosapien]

No I couldn't see the point either, hence moving to a simpler architecture when the opportunity arises.

The only benefit of the simple buy many layers was that they used a code generator to knock out most of the code, then tweak it where necessary.

On the first clean slate project I worked on at the client they initially wanted us to use the same architecture for consistency. After mulling it over for a few days, seeing how much work would be involved in setting up the code generator for the new system, we decided nah it's too nasty so proposed a fresh approach.

Gladly we didn't have to subcontract the persuasion out to MF and his penchant for knocking out PMs, as the client's cookie policy wouldn't stretch to a full on cookie monster.

[MicrosoftBob]

I agree with you, but how can you put that across at an interview without looking awkward ?

[woohoo]

No I couldn't see the point either, hence moving to a simpler architecture when the opportunity arises.

The only benefit of the simple buy many layers was that they used a code generator to knock out most of the code, then tweak it where necessary.

On the first clean slate project I worked on at the client they initially wanted us to use the same architecture for consistency. After mulling it over for a few days, seeing how much work would be involved in setting up the code generator for the new system, we decided nah it's too nasty so proposed a fresh approach.

Gladly we didn't have to subcontract the persuasion out to MF and his penchant for knocking out PMs, as the client's cookie policy wouldn't stretch to a full on cookie monster.

Reminded me of a system I inherited a few years back. Everything including the ui was generated from the db. They had developed their own tool to do this.

The guy who did it left and I replaced him, unfortunately he had several versions of this code generator and none of them produced the sane code as in production.

Oh that's was fun.

[DimPrawn]

[Hobosapien]

We need technical archaeologists to dig through the layers for the project artefacts.

Yet the dinosaurs are the ones creating the new layers. Seeing the size of them I can see the benefits of the Lean mythology.

[firestarter]

Never seen so much hate for DI frameworks. Is there a similar disdain for loose coupling and unit testing as well?

[firestarter]

If 'component' == a class, then yes. But then those tests probably suck.

So ComponentA has a bunch of logic in it, including calling ComponentB.

You don't see any value in being able to test ComponentA in isolation?