Overarchitected Projects

[DimPrawn]

That is the problem. Ba**ard self centered contractors adding in nonsense for the sake of it.

Oi!

I resemble that remark!

[woohoo]

I actually quite like DI frameworks - but buried down below the surface. Inject the factories, and have those factories build nice coarse grained objects with their dependencies hard-coded if you like.

I don't get the obsession with never being seen to be hard-coding any dependency, while hard-coding them in some uber DI config file somewhere.

I like DI because I've been in situations where I've found it useful for example I've moved a whole load of repositories from EF to Dapper. I could swap between classes in one place which is very convenient. It's also good for short release cycles, you can be working on a new replacement class but if it's not ready for the release just swap it back in the DI file. I also like to see less code in methods, i know it's only a few lines creating a new instance and passing the params but still it's not needed.

I find that it also encourages developers to use interfaces which often helps drum into them the importance of keeping your classes to a single responsibility. Also, makes developers think a little more about design before diving in.

I've gone off TDD/BDD. but yep it helps with mocking.

I will say one thing though, in the past I used Entity Framework alot but I really can't see that advantage of using it over a micro orm. I'm at the stage now where I would avoid a contract if it had EF in it - it just seems a mass of over complications for what is essentially getting data out of a db and mapping it to a class or collection.

[DimPrawn]

I like DI because I've been in situations where I've found it useful for example I've moved a whole load of repositories from EF to Dapper. I could swap between classes in one place which is very convenient. It's also good for short release cycles, you can be working on a new replacement class but if it's not ready for the release just swap it back in the DI file. I also like to see less code in methods, i know it's only a few lines creating a new instance and passing the params but still it's not needed.

I find that it also encourages developers to use interfaces which often helps drum into them the importance of keeping your classes to a single responsibility. Also, makes developers think a little more about design before diving in.

I've gone off TDD/BDD. but yep it helps with mocking.

I will say one thing though, in the past I used Entity Framework alot but I really can't see that advantage of using it over a micro orm. I'm at the stage now where I would avoid a contract if it had EF in it - it just seems a mass of over complications for what is essentially getting data out of a db and mapping it to a class or collection.

Pretty much agree with what your saying. EF seems like hard work, I use Dapper whenever I can. So much effort for object persistance into the Relational DB, when in these situations a NoSQL object database works much better.

[SpontaneousOrder]

They don't believe in the XML hell that is other DI frameworks.

In java land it's all annotations or DSLs these days.

But that's the smell right there - XML hell. If you have enough XML for it to be hell, then you are almost certainly configuring fine-grained dependencies for no good reason. DI *frameworks* should be for switching out things at the component level. For example, if you need test versions of classes, then inject a test version of the factory that builds them. Don't configure xml for every single class dependency

[Hobosapien]

EF with XML hell (the model is too complex, or broken, to load into the Visual Studio viewer without it crashing so have to open as XML to make changes) is part of one project solution I've inherited.

The previous contractor still had to abandon LINQ and go direct to database using views and stored procs for some of the more complex data manipulations. There's even nested views with pivots and all sorts of stuff going on. Not exactly easy maintenance.

Overall it feels like a right mess and I think I may only get chance to do any serious refactoring (ideally rip the lot out and replace with Dapper.net) if the performance hit of LinqToEntities gets worse as they pile in loads more data.

So contractors, before you decide to use that new fangled technology so you can put it on your CV please remember it may be another contractor that has to inherit your crud.

[woohoo]

So contractors, before you decide to use that new fangled technology so you can put it on your CV please remember it may be another contractor that has to inherit your crud.

Did not think EF was new fangled tech, was using it years ago, sounds like your predecessor made a bad job of it. Most contractors being experienced and competent do a good job, you got unlucky.

[Hobosapien]

Did not think EF was new fangled tech, was using it years ago, sounds like your predecessor made a bad job of it. Most contractors being experienced and competent do a good job, you got unlucky.

I think some of the pain comes from them using EF when it was first released as the code goes back to 2008/2009 and having to workaround the then limitations. Typical 'use something new coz we can' scenario, learning as they went along.

Part of the problem with contracts and project based work is there's not always enough flex in the schedule to do some refactoring that really only benefits the sucker landed with the mess.

As the system is now 'legacy' I expect they'll replace it rather than rewrite it at some point. I'm sure the code is self documenting enough for the next victim that comes along.

[suityou01]

Did not think EF was new fangled tech, was using it years ago, sounds like your predecessor made a bad job of it. Most contractors being experienced and competent do a good job, you got unlucky.

Does sound like one of DP's projects to be fair.

[Hobosapien]

Does sound like one of DP's projects to be fair.

Could be. There were two of them on the original team, Parker and Bic. Though it passed the pen test.

[Jim Spector]

I think we have spaghetti everything Yep I've seen the same with WCF and I've worked on projects where everything talked to each other via wcf and lots of different patterns- right pain. It was clear that know one understood how or why the project was put together that way and when I made a fix, I would look in the history see something similar and make the changes in the same files. It was clear other people did exactly the same.

I tend to keep it simple with a repository using dapper and a UI project. Do use service classes but only for things that don't necessarily fit into the repository or the controller. I was watching a video from a guy from Israel and basically he was saying don't use a repository do everything in the controller, so using linq accessing the db from the controller. His argument was that you rarely reuse repository methods and end up with a load of similar sounding and doing methods or lots of overloads. Don't quite agree with him on everything but was interesting. Oh I actually quite like dependency injection, sorry

I was hoping for more replies with other useful tools but there you go. Anyway good luck!

+1 for keeping it simple, so often that principle is lost.

IMHO the repository pattern is redundant if you are using something like EF; the data context IS the repository. Dapper is great though a thin wrapper around it is probably a good idea to avoid having raw sql statements in api controllers say. This could be as simple as some additional extension methods on IDbConnection.