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 8 years ago.
Improve this question
In theory a large 1000+ line of code behind code is "bad practice" what if the majority of the code effects controls on the page?
For example what if there were 30 text boxes to collect user data, but depending upon answers to questions, visibility, validation, etc changed on these text boxes.
Should you then be writting methods in classes for validation that take collections of text boxes and disable validation, or set the visibility? I'm having a hard time wrapping my mind around the design practices of large code files.
I guess I'd like to know the best practice for breaking out large code behind files that still allows for easy control manipulation.
I'd devide the text boxes into groups depending on the contents. Make a User Control for each group (With a dedicated visual container). A user control can take care of validation and some computations, but it is very readable and can event be reused somewhere else if the problem you are solving allows that.
Another option is to use a wizard. This could be more complicated, but if you have the time, you can get nice results.
First of all I do not think 1000+ is not too much for a code behind file at all and I wouldn't consider this bad practice as long as you follow the DRY ( do not repeat yourself ) approach. If you really want to split this up there might be a possibility to have more code behind files for group of controls and do ajax requests to validate parts of the page. You could then evaluate the results from the ajax calls and check if the return message is success and assume that the validation is successfully if all individual ajax calls have a success flag.
For ASP.NET I do most of the logic on the client side with the knockout framework using the visible binding:
http://knockoutjs.com/documentation/visible-binding.html
I use knockout to generate the controls via foreach binding and set the visible binding to an observable inside the obserable array. If the array you pass to the foreach binding is an obserable array you can also add / remove controls via JS.
You could use a validation framework and on validation you can change the observable array adding more questions / removing questions from HTTP post.
Another option would be to do the validation on the server side.
You can check in the post method the values which have been submitted and change the view model adding or removing elements. You then return the view with the modified model.
If required I would use a strongly typed collection to have a reference for the page elements and modify the properties as required.
For WPF I use Observable collections to track property change events which notifies the UI when the collection changes.
Related
I'm fairly new to ASP.NET and programming in general, and one of the problems I'm currently struggling to grasp is reducing repetitive code.
My goal is to have a master page that contains a grid view, then numerous pages can contain the grid. However, I want to be able to share code between my grids but at the same time be able to adapt unique code to each and everyone of them as some will have different attributes and data.
I've looked into separation of concerns, and other various posts/blogs but haven't found a definitive answer to how I can actually achieve what I want.
I've already tried using master pages and it worked quite well until my application continued to expand, plus I'd prefer to only use my master pages for presentation.
Could anyone provide a simple example of how I can achieve this?
Happy to provide additional information!
After spending the day doing research and testing numerous possibilities I've pretty much answered my own question.
I've setup a master page that contains the grid, the content page then retrieves the grid using accessors. This grid is then set to a property in the base class which makes it accessible where I need it to be.
edit
Event handlers were created to handle the grid events in the content pages, then those methods were overridden to allow the calls to bubble up to the base class thus allowing me to assign unique, page specific and common code where I needed it to be.
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 6 years ago.
Improve this question
i use the following pattern/style alot in my applications/programs and want to know if this is a common pattern that i don't know.
When i must write an app that is like a big function that get the input data from different sources, do the processing and create the output. Like the IPO Model (input-process-output).
I have one class/type that represents only my state/data which has no logic. Most of the time i name it Context, ExecutionContext or RuntimeContext. I also have multiple classes/types that contains only logic as stateless funtions (in C# static methods in static classes). After my entrypoint of the app, i create the context at first and use it then as arguments for my functions. The context holds the complate state/data of the app and all my static functions/methods manipulate the context. At the end of the functions chain and the call/execution is done and the context holds the final state if i need outputdata.
I try to create a picture that visualize these approach
The advantage of these pattern is
i can simple test my logic (small pieces of static functions) with
unittest
it is not so hard to use concurrent code (only the context need threadsafe code)
dependencies to other systems a mostly decoupled as abstractions (interfaces) in the context (for example an IDbContext). That make the testing of a bigger scope simple
And here is now my question. Is this a common pattern? When yes, how is it called?
Thanks for every hint! :)
regards
This looks like a Dataflow.
The functions are black boxes which act on the data provided to it. Dataflows are turing complete, and can even model traditional imperative flow control structures.
When you issue a request to ASP.NET MVC, it has an entry and at the end it returns an output. ASP.NET MVC is open source and there are tons of diagrams which explain the whole pipeline and how it works. It is also very customizable so developers can plug their own classes in, intercept certain events, hook into certain parts (filters, authentication, authorization etc.)
If I were you I would start looking into that and borrow some ideas from it. You don't event have to look at the source code. You can start by looking at the diagrams for the pipeline and see what it is doing and how it is doing it.
Right now your code is just functions which are executed in a serial manner. If you want to use Object Orientation, take advantage of interfaces and allow customization, event interception, hooking etc. then it will be difficult.
Here is the diagram in case you are interested.
Well, it's common in IoC-style apps, where services/repositories are singletons and, as so, stateless.
The advantage of this approach is that it saves a lot of memory and some time (no need for new instances of components to be spawned). Disadvantage is that you somehow lose the OOP aproach and also is hard to maintance in bigger picture without strong interfaces support and IoC/Dependency Injection container.
Also look at ThreadLocal<> mechanism build into .NET - that way you don't need to pass your context explicit, but rather than that access thred-scoped global variable that contains it (but then - you need to watch out when branching threads, another topic that IoC/DI handles).
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 6 years ago.
Improve this question
I've got an WinForms application that uses MVP and I'm not entirely sure how to approach the scenario of when I need to create new UI elements.
For the sake of example, let's say my view has a button which is supposed to open a new view (Form) as a dialog. Is the view or the presenter supposed to create the new view or is it the job of the presenter?
This is my thought process:
The view should create it as it as a UI specific operation. But...
The presenter should do it because the view is just supposed to be passive. But the presenter shouldn't know the specifics of the UI.
Which is the correct way to approach this?
I've seen this done a couple different ways. It's funny how all the patterns seem perfect on paper and then implementation details show how it's not that simple. I'm going to give examples as a MVW (model-view-whatever) because it should be similar in any pattern.
Option 1:
Bind to a property. This is a little more difficult with WinForms but works great with WPF. Have your button set a bool property on your presenter/controller/viewmodel. Your view then simply shows or hides it's UI based on this value. The UI can overlay all existing UI to have the appearance of a modal.
Option 2:
Services. Introduce a DialogService (hopefully you have dependency injection set up so it's trivial to add). This service has a method of ShowDialog(options). Options could be title, message, commands (with titles and actions for button). Have your button set a property or fire a command on your presenter that then calls it's dialogService's ShowDialog method. This way your view is still just simply calling your presenter and it is using the service. Views shouldn't know about services. This allows your DialogSevice to construct the appropriate UI and then launch the new form. This is also how I like to wrap up the native MessageBox.Show calls so you can replace all these with a DialogService.
Option 3:
Don't be a purist. If your modal doesn't need to interact with a presenter or you simply want basic data back (say a color picker or something like that) then just let your view take care of it. Your button can simply open the modal, the modal has values that are sent back to the view. Then your view uses them. If the data has no reason to make it back to a presenter, don't over complicate things to be a purist. Views can still perform UI based logic. I use the view for many UI only things such as moving elements around with mouse/touch events or pinch to zoom calculations. If logic is UI only, keep it in the view's code behind. If it's repeated UI logic move it to a service or user control or custom view.
In all the MVP/MVC/MVVM docs, they are always missing crucial details. To me, Services is the missing link. They allow loosely coupled logic to be plugged in and you can wrap up some of the ugly UI bindings or UI events into services and keep things tidy.
Hope this helps.
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
If I`m not mistaken, Remote Attribute Validate execute on Value Change, so it doesn't require you to press Submit, However Custom Attribute requires that we Write JQuery to call Adaptor
So my Question is why not use Remote Attribute all the time ?
The primary purpose of a RemoteAttribute is to perform validation logic in the controller while staying on the same page. Most often its used when you need to access an external resource (for example to check that a new user is not using an existing user name when registering), but it could also be because the logic is so complex that it is not worth duplicating/maintaining it in a client side script.
Two important things to consider about the RemoteAttribute.
It uses ajax to make a call to a server side method. Initially the
ajax call is made after editing a control in the .blur() event,
but thereafter on every .keyup() event so using a
RemoteAttribute will be a performance hit
It provides only client side validation (which should only ever be
considered a nice bonus) and you still need to then implement server
side validation to prevent a malicious user by-passing the client
side validation
If your writing a custom validation attribute where the validation logic can be performed using javascript, then your attribute should inherit from ValidationAttribute and implement IClientValidatable (and include the necessary scripts to add the client side rules) so that you get both client and server side validation without making unnecessary calls to the server.
Refer The Complete Guide to Validation in ASP.NET MVC 3 - Part 2 for a good article on implementing custom validation attributes.
I use update panels all the time when i wanna to update specific part of my page but recently i face performance problems ( i mean it 's slow in rendering the intended control and sometimes it doesn't work and need multiple click to work !!
so my question is :
Is the page method could be considered as an efficient alternative to
the update panel and do the ajax magic ?
What are the other alternatives?
please if possible a simple example to clarify how to replace the update panel using with page methods ?
I used to be like you some years ago, I used to use UpdatePanel to gain performance, to have the wrong idea I was increasing the performance of my applications...
Well I was totally wrong, UpdatePanel is the root of all UI-evil, first of all it hides the complexity of using AJAX which makes it easy for most of us, giving us the wrong idea that we are creating responsive applications, which is worst than if we weren't using it at all (that's the main reason I used to use it in all my pages, and I am sure that's the reason why many developers use it... 'cos it's easy).
Consider the following articles:
Why you should not place your whole site in an UpdatePanel
UpdatePanel is evil
When you understand what the UpdatePanel really does against a simple call to a PageMethod or a REST WCF Service, you will see the huge difference between them.
UpdatePanel. When you perform a post from an UpdatePanel, the whole page life-cycle has to be executed, this means, it requires to send all the page ViewState on each post, when your page grows in complexity with several controls, the ViewState will certainly be huge and this will certainly be a performance issue. Using them you only gain partial rendering, the controls inside your UpdatePanel will be rendered without a full post back although you need to send the whole ViewState on each request.
PageMethod. Page methods are static, they are called like if they were a service method, they do not need to create the whole page life-cycle in order to be executed, therefore, they execute faster.
So it would seem that using PageMethods would be the solution, the problem is that PageMethods are usually used to return JSON objects which means, that you will have to render these objects manually. This means that if you want to get rid-off all your UpdatePanel you will have to change the controls used in your views, you won't be able to use the GridView out-of-the-box for example, instead you would have to change it for the JQGrid (or similars).
This is natural if you are creating a MVC application, but with traditional ASP.Net this is not straightforward.
You also need to consider something very important, the ViewState is validated by default on each post, you can turn it off, but it is not recommended if you want to be sure your ViewState has not been corrupted (take a look at this question).
Consider this example, you have two DropDownList controls, (named: ddl1, ddl2) ddl2 depends on ddl1 so using the SelectedIndexChanged event you fill the second drop down list. But if you attempt to do the same using AJAX calls (without an UpdatePanel), you will face two problems
Rendering, you need to manually add objects to the HTML select control representing the DropDownList. You could use a third party framework to bind these controls using javascript, I can recommend you knockoutjs (it's awesome)
This is the problem. After you have changed the content of the second DropDownList using javascript, you cannot do a simple post to your page because the ViewState will not be valid, and you will see the following exception:
Invalid postback or callback argument.
The workaround is to specify which values will be valid in the server side, in order to do that you need to override the page Render method and specify each one of the values of the second drop down list, but this will increase the page size and obviously, this is not a good option
Take a look:
ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part I
ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part II
So as a summary, if you want to get rid-off all your UpdatePanel controls, you will need to replace the existing server controls for javascript-friendly controls. Also remmeber that if you do that, instead of relying on the page post mechanism, you would have to use AJAX to perform operations on the server, otherwise, you will get the Invalid postback or callback argument. exception. In other words it would be better to consider moving to a MVC application if possible.
There is an alternative to UpdatePanels, but still using PageMethods. It is a combination between jQuery and jQuery templates. It is proven to be faster than the UpdatePanels. Further reading on the resource below, where you can find more articles dedicated to this topic.
http://encosia.com/use-jquery-and-aspnet-ajax-to-build-a-client-side-repeater/
You might read about the coming WebAPI in .NET 4.5. It's for WebForms as well as MVC and may be a viable solution to your problem if you can wait on 4.5.
Just use it in combination with any jQuery template engine.
http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx
Have a look at http://uframe.codeplex.com/