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.

  • 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 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 at 13:03
  • 1
    Possible duplicate of Choosing the right Design Pattern – gnat Aug 10 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 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 at 14:51
up vote 1 down vote accepted

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.