Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am currently maintaining an application where unfortunately we have ended up in having too many Action methods. On top of this the architecture of this project is not fair from the beginning and every developer continued adding Business logic in the action methods of the Controller class instead of keeping it in another business layer.
So now one of our controller class has reached 15000 lines of code and I don't want to flood even more this class by adding another action method.
Any suggestions on how we can refactor this or can we use any partial controller class or any other better way?
N.B: I know we can use thin controllers by moving the code to another layer, but still we will end up with too many methods.
15,000 lines, jeez.
Aside from what you've obviously stated about moving the code to the business layer (which you should do), I would also consider forming logical groups of those action methods that belong to a certain set of functions.
Once you've got these groups, create separate controllers for each of them, named appropriately. This way you'll clean up your controller and you'll also segregate sections of functionality into their own logical groupings.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
If I have a number of pages that all have 3 common fields, is it recommended to have a base view model class that contains these 3 fields, and then on the viewmodels for each page, inherit from this base class?
I read somewhere that this was bad practice, but I’m not sure why. As it’s removing duplication and the validation still works etc.
Thanks
Jenny
I would suggest using composition rather than inheritance. Put these 3 fields in a separate class and have a property of this class in each view model that needs them.
Composition tend to be a bit more flexible than inheritance. A typical example would be that you can only inherit from one class, but you can have as many properties as you would like.
In my opinion, this is bad practice as your project gets more complex you will need to make changes to your fields and one template you use as base class might contain different amount of fields than you needed initially.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to determine the best approach for returning different objects from 1 REST endpoint.
Example:
Suppose the client has a Customer ID: 123 and calls GET /api/customers/123
The consuming client has no other knowledge of the customer, other than the ID
The customer returned can either be and Individual or a Business, each with their own unique properties. Each of these objects can be updated
My current design has multiple PUT endpoints to support the unique updates
PUT /api/businesses/123
PUT /api/customers/123
The problem I see is the client now has to call another endpoint to perform the update on the Business customer which makes the API more complicated to consume and I'm not sure its best practice to return different object types from 1 GET endpoint.
Are there any alternatives or does this approach seem reasonable?
EDIT: So I think my problem is more due to the fact that I'm treating these entities are truly unique when in fact, they are the same (barring some meta data properties). #Patrick Hofman and #LB2 for your answers. I will refactor
You can use HATEOAS as means of directing client where respective relevant resources are.
The model that backs the GET call would pretty much be combining data properties of both models - whether that's a good idea or not really depends on how disparate are your Business and Customer models. If justified to be close to similar with minor differences, then perhaps combining is reasonable.
For each type however, you would generate the proper link for PUT, directing the client as to where to do the update. What to send for update would depends on contract between your service and your client.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm writing an application in WPF and found myself loving whole MVVM paradigm. My only concern at the moment is that my ViewModels are becoming heavy. They contain Commands, logic to enable and disable buttons, instances of other ViewModels, async method with DispatchTimer timers etc. Is this something that is normal in this kind of development environment? Or is there some logical way of organizing ViewModels without becoming too "crowded"?
Keep in mind that the ViewModel is just an adapter between your model, where logic and data live, and the view which is shown to the user.
The idea is you can easily swap views or change them, without the logic suffering from that.
Having said that, depending on the complexity of your application, they might grow quite big, but if it's mainly stuff that ends up enabling/disabling stuff on your view, and isn't doing logic / processing stuff, I'd say this is where it's supposed to live.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
For my company, I have developed one winform application, that handles Unified COmmunication.
It's been 1 year in development. I Just write global functions in seperate classes, and write the code in either form or class. Now They wanted me to make three seperate copies(UI of each changed) of the same Software. I have changed all UI and everything needed, and made 3 copies. But now, I feel it very difficult to correct any issues, or add any features. I have to change it in my all three copies. How can I solve this. Thanks.
I'll assume the three versions are very similar. First off, it's of the utmost importance that you keep your project under source control.
Personally, I would have created a dev branch for the main version, and then create two other branches for the 2 other versions (e.g., dev-v1 and dev-v2), created off the main branch.
Then, whenever I had to apply a patch to all 3 versions, I'd do it on the dev branch, and then merge dev with dev-v1 and again with dev-v2.
So far I only addressed the source control issue, but as CSharpie pointed out in the comments, you should definitely separate the presentation layer (i.e., forms) from the business logic. Furthermore, these two should also be separated from the data layer.
Take a look at Multitier architecture.
Separation doesn't necessarily mean different projects or solutions. Having a logical separation (e.g., having sets of classes with very well defined purposes, following the SOLID principles etc.) is often enough. In your case, however, it seems that the presentation layer should be in a different project than the other two.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
This is my first question here so let me know if additional info is required...
I am new to designing so my knowledge is a little limited, so I have this application in which I have a project class, the project goes through 7 stages, and those stages have nothing in common...first one is Discovery, which contains question about the requirements, second is Product Mapping, which lets the user select products required by the project...
The problem comes, that stages keep on getting added or removed...
So I cant put their reference in the class, cuz then I need to modify the class every time. So how to design the flow?
Should I pass the project object into stage object? Then how to keep track on which stage the project is?
I think you should go for Process Manager Pattern.
Each of your stages should be separate class implementing a common Interface/Abstract class(according to your need) and then you need to have a Controller class which will control the work flow of your project. You can add or remove your steps to this Controller class instance as per your requirement.
You can track the "status" of the Project as Project.status, being an enum that advances through the appropriate stages. (This assumes that each stage exists only once; it can be re-executed, but would update/ overwrite the previous results.)
Data captured at each stage can be implemented as properties in the Project class (most simple), or (more advanced) "pushed down" into composite entities per-stage.
Don't forget also to take advantage of entities/objects to hold information like Requirement, Product Mapping etc!