1

Our system was initially created around the client's ordering logic which is received by an API. This was allowed by the previous I.T. dept.

However over time (after growth) many different clients with differing systems send their order's to our API which have to be cleaned and changed into our working version, examples are filenames without file types for images which have ',jpg' added to the filename, or statuses that are strings ie 'finished' that are converted into our new status of int 2 etc.

There are huge sections of if statements and switch statements that change things based on who the client is which has created God controllers which have all this logic whilst the models are anemic, and I need to service the code whilst refactor as I go, but there are little in the way of tests etc.

I want to use SOLID principles and learn better programming and move the logic to the models for reuse, create viewModels, move javascript out of HTML pages and into javascript files and remove duplicated code which seems to be everywhere.

I'm not looking for a way to decide on design patterns, but want to know what design pattern(s) are best to have a core logic and surrounding client specific logic when refactoring God controllers.
Ideally I would encourage a single robust logic with customers overtime that would accept certain variations.

Whilst I commented on a service architecture it seems that we are not using the service pattern.

and
  • 31
  • 5
  • 2
    So, what have you decided about your model? Are you trying to keep it anemic or do you want to move the logic into the model itself? There are several routes you can go, from a more Domain Driven approach to a service oriented approach. In either case you'll be moving logic away from the controller and centralizing it elsewhere. The all important question is, _what is your goal for the end product?_ – Berin Loritsch Aug 10 '18 at 12:47
  • @BerinLoritsch I would imagine a service oriented approach, as there are a raft of services used already. I certainly want to remove duplicated and high maintenance logic from controllers and put it into the model/services. – and Aug 10 '18 at 13:03
  • 1
    Possible duplicate of [Choosing the right Design Pattern](https://softwareengineering.stackexchange.com/questions/227868/choosing-the-right-design-pattern) – gnat Aug 10 '18 at 14:04
  • I think you're going about this the wrong way. Design Patterns are not a catalog that you can leaf through and find the right one; they are well-known solutions to commonly-understood software problems. You need to already know the design patterns to recognize that one of them solves your particular problem, and there's no guarantee that such a pattern already exists. Your approach is a bit like trying to find a word in the dictionary by looking through the definitions. – Robert Harvey Aug 10 '18 at 14:48
  • As to your specific problem, I think it would yield to ordinary refactoring techniques. It's hard to say for sure from the general description you have provided. Consider posting a sample of your code a Code Review and see what they say about it. – Robert Harvey Aug 10 '18 at 14:51
  • @RobertHarvey Thanks for dispelling my guess that design pattens would be a great help. I've been looking at the code from a more domain driven aspect and agree that I will get more from ordinary refactoring techniques, and my company are becoming more visual and functionally critical. So moving logic away from the controllers and views will be most critical. Thanks for your help here – and Aug 12 '18 at 21:20
  • @BerinLoritsch there isn't a service architecture and I agree with you're, and other comments about ordinary refactoring techniques. thanks for your help – and Aug 12 '18 at 21:22
  • If I said "Use Factory pattern", does it help you? – Fabio Aug 13 '18 at 06:01

1 Answers1

1

From the comments here I have determined that the code base is a domain driven one, and that the project will be have its gui updated/changed as well as having extra functionality added over time. So ordinary refactoring techniques will work best as I must move logic into the models/viewModels, make better use of the MVC patten by correctly using partial views, and reusing code.

and
  • 31
  • 5