I have an edit page which is grows with the size of the app. We're now running in to a situation where the server side action (MVC) is handling image uploads and conversions alongside regular text saving to database.
What's the best way to make this more maintainable? Separate controller for images uploads, so that we create an writeable API? Or more actions within the same controller?
There are few ways, which could let you mitigate the problem with rising complexity :
Implement HMVC, where each controller calls sub-controllers. This would let you to split up the "update" tasks in logical and manageable chunks. Especially, if i am correct in thinking that there is more the one "update page". The HMVC structure would let you to assemble different update pages from existing fragments with quite minor additional hustle. Main disadvantage: relatively large change in architecture.
Split the update page(s) in smaller forms, each submitting to a different controllers action (or maybe a different controller altogether). Main disadvantage: user can update only one part at the time
Evolve the model layer, so that the API you use interacts with service layer instead of domain model layer. This will let you isolate the complexity of updated and provide a simpler interface to use in controller. This too would have the added benefit of composing update form(s) from manageable pieces. But i don't know the penalties that come with this approach .. never have used it myself.
The bottom line is: you will have to change one part of MVC. In your situation i would choose the HMVC way, but mostly because i am familiar with it, and multiform page might induce rage from users.
Related
I have an ASP.NET Blazor server-side project, using EF Core. One of the pages is getting quite large. Apart from any other reasons for keeping code files a reasonable size, the large size causes significant delays when recompiling.
I would like to split it down into smaller components, but the problem is that the whole page represents a fairly large object graph, parts of which are used in multiple places on the page.
Imagine a page that shows details for a company. The company has many employees, each of whom can claim expenses, which are added to the company's transactions list. The company itself has income and expense, so that adds more transactions. Other parts of the company object graph might also have associated expenses. This is a very simplified (and fictitious) sample of the idea. The page has various sections, such as one for employee details, which shows their transactions, as well as an overall transaction list.
At various places, you can add transactions, which get associated with the employee (or whatever), and are shown on both that transaction list and the main one. All of this is done with individual forms for each action, it's not one huge form for the whole object graph.
If I were to split the component down, I would be faced with one of the following choices (unless someone can suggest another)...
Have each smaller component inject its own DbContext and handle its own data access. This is fine in theory, but would cause concurrency problems as it would mean that different components were saving changes to the same entities. It would also require a lot of events to inform the parent component that data had changed in the subcomponents, which would end up very messy.
Have each smaller component have parameters for the bits of the object graph they handle. This avoids any concurrency issues, as only the parent component would be doing any data access. I'm not sure if it would avoid the need for events, as it depends on how well Blazor would notice if a part of the graph passed to a subcomponent changed.
Pass the DbContext in to each smaller component as a parameter. Again, this avoids any concurrency issues, but really feels like the wrong way to do it.
Anyone able to guide me as to the best way to split this up?
Thanks
If you have lots of sub-components accessing the data in the Form [your top level component - some sort of dashboard?] then you probably have quite a bit of plumbing to try and keep everything in sync, or lots of rendering going on if you are cascading objects. How often are you calling StateHasChanged?
Without some code I can only answer in very generic terms.
Your first step is to separate out your data and data management from your components and form. Move the data and the database into a DI service. The scope depends on what you're doing: Transient or Scoped. You can then use normal events to signal updates to components that need to render if something changes. There's an answer here that shows how to do this - https://stackoverflow.com/a/69562295/13065781.
[Opinionated] You also need to understand that by building a complex object (your DataGraph) and then letting EF manage it's state, [in Clean Design terms] you're building core application logic (the relationships between your basic data objects) into your infrastructure layer. The advantage is it makes things easy, and saves a lot of coding. The disadvantages come to light over time.
I'm developing an Angular2 workflow app that collects data on multiple tabs, customizing the fields on each tab based on prior tabs' values, and then validating that all tabs are filled out correctly along the way. I'm using the Angular2 router to control which tab component displays, and each tab uses FormGroup to handle form validation. (See below for a visual idea of component hierarchy and how the app works.) I need an elegant way to compute the validity of data across all tabs in the workflow, without having to open each tab to activate its controller and FormGroup validators. Ideally, the workflow validation for a tab will use the same logic as the tab's FormGroup validation, to keep things DRY and consistent.
As users touch fields I log the tab's "dirty" state in the DB, so I don't have a problem knowing when a tab is pristine/dirty. The challenge is, when a user returns to a previously-saved workflow, how do I compute the valid/invalid state for all tabs' data, when the user hasn't yet touched the FormGroups on those tabs?
Thanks for any suggestions for design patterns that can accomplish this!
A few design details:
One route component handles each step of the workflow.
Each route component uses a FormGroup to handle form validation.
Form validation on all tabs need to drive the valid/invalid indicators for all workflow steps, shown in the header's .
A tab can be in one of three possible states: Pristine (gray check: the user hasn't touched any field on the tab yet), Incomplete (red exclamation: the tab has been touched and one or more fields on the tab are invalid), Valid (green check: all required fields contain valid values.
In working on this problem, I am finding that the solution requires higher-level architectural choices about state management and how to handle & display the app's data. Unfortunately for me, there wasn't a single technical solution, like "Use this Angular2 library design specifically to validate fields across multiple FormGroups in different components!" :(
I hope our research is helpful for somebody else, my team is taking a Redux approach using the npm modules ngrx-store & ngrx-effects for Angular2. All of the app's data & state processing logic (including validation across multiple tabs-- my initial challenge) will be handled by Redux actions & reducers. A beneficial side effect is that our view controllers become super simple, and just display the data ngrx gives them. This eliminates complex, conditional logic that depends on state of data entered in other areas of the app.
Egghead.io has a useful 10 minute video that introduces the ngrx library & design patterns.
I hope this gives you a leg up. Good luck!
Four years later, I have a better answer to the initial question:
There's a module for that! https://www.npmjs.com/package/#ngneat/forms-manager
For state management in general, I now use Akita, https://datorama.github.io/akita/. I hope I never have to use redux again. I imagine there are legitimate use cases that need redux, but having now used ngrx in a few projects, I can say with confidence: It is very complex to implement and maintain, and painful for each new team member that has to come up to speed.
Both tools are created by (or at least heavily contributed by) Netanel Basal (https://netbasal.com/), so it's also nice that they share the same mindset about state management.
I am using .NET MVC 4. Let's say I have a Pinterest-style social media site. Users can pin content (ie., images), and decide the layout of their pinboard by dragging/dropping images around the board.
How do I persist the layout they've made so that when they log-out/log-in, the content appears exactly as before? All DOM elements with associated IDs, classes, styling, etc. need to be saved. I would need to "auto-save" these layouts as well.
The best answer I could find was this one:
How to persist changes made to Rails view rendered at client?
But this fellow seems to be saving the actual HTML mark-up. I think that will become very inflexible very fast. I thought I should be persisting the DOM tree itself, or possibly take the ReactJS route for designing my views, assuming ReactJS lets me save its VirtualDOM (or an instance of the actual DOM) to a database that it can then re-render upon log-in.
What am I missing? I've searched high and low for this but with out much luck on how to solve this problem. Any help is much appreciated!
I'm planning out a web application using Laravel for the server side structure. The main goal of the application is to display a form that will allow the user to enter in Parent/Guardian and related Student information. The additional goals will be to allow administrators to log in and look up Parent/Guardian and Student data that has been submitted.
At the simplest, I feel like I could do this by using one controller for "Form" that facilitates the display of the form, the submission of the form data, and the showing of the stored data.
Thinking forward though, it seems like it would be beneficial to have the logic for the Parent/Guardians and the Students in separate resourceful controllers to make it easier/clearer to access and work with the logic per entity. If I did it this way though, it seems like I would need a third controller for the Form that would then call out to methods in the Parent/Guardian and Student controllers separately.
What would be the best way of approaching this structure? I want to go for the "pass the salt" or "just program what you need now" approach, but I know that I'll need more refined access to Parent/Guardians and Student data in the near future. My goal is to minimize the amount of refactoring by planning well at the beginning.
Any suggestions or insight would be appreciated.
Thanks!
My app uploads an image and stores the image info in the database. If needed it manipulates the image. There are several points in the site where images can be managed like this.
In each case I have an action imageuploadAction() that handles things. Because I have slightly different requirements depending on the part of the site the image is going to be used in there are several different imageuploadActions in various controllers of the site. I want to combine them all into one, however, to make the app easier to manage.
So, my question is what is the best way to handle a site wide image upload capability within Zend Framework? I feel it must either be:
Have one action that does it all and the various controllers would use that action, or...
Create some sort of plugin that does it. An Action Helper Plugin perhaps? Maybe a controller plugin of some sort? What sort of plugin is the best way to do this?
I'm inclined to think 2 is the way to go but want your feedback on this. Thanks!
Oh, and the plugin (or action) will handle physically uploading the photos, categorizing them, flagging them for various uses, resizing as needed, passing data to the DB for all CRUD actions as necessary, etc. etc.
What you are describing is what action helpers were designed for, so I'd suggest creating an action helper for handling uploads and moving as much of your processing code into that as possible. However you still need to call that helper from your controllers, so then it really comes down to what suits your application - a central controller that handles the uploads (by calling your helper) or calling the helper from the relevant points in your existing controller methods.
If you can get to a point where your image upload actions are as simple as this:
public function imageuploadAction()
{
if ($this->_helper->HandleImageUpload([...])) {
[...]
}
}
then I'd say you're in pretty good shape, and you can always reuse the helper elsewhere if any parts of your app need to handle an image upload and some other data in the form at the same time.