I am working on a very LEGACY ASP.NET MVC app using C# which is built from 2009. They don't have any client side validation at all. In other words, they don't use validation mechanism provided by the ASP.NET MVC framework as the following link
https://learn.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-5.0#client-side-validation
They use service, interface etc... to do validation. Not using data annotations, either. As a result, they don't have unit tests for model validator. All validation rules will be tested manually through server side only or the unit tests have strong dependency to Resource.resx or other services which I don't think they are unit tests.
Therefore, I have added a client side validation and server-side validation by using data anotations.
Unfortunately, my PR is declined because they said that they don't want to use or add jQuery to the current application.
The reason is that: "they want to build portable micro-frontends pointing at APIs rather than all encompassing large applications the current app. because of that jQuery Validate is at the complete opposite end of the scale from zero compromise. It can be done by HTML5 and plenty of other client side only JS libraries there are plenty of better compromises. The other end of the scale (our ideal) is the validation happens in an encapsulated web component that uses Angular Forms." (An answer from a Front end developer)
The problem is that we have not the plan to replace that legacy app yet and I don't see the reason why I cannot use Validation mechanism from Microsoft to do both client side and server side validation. My thought is that it is better to do validation in correct way, rather than let it be bad and will be replaced by web-component soon.
Based on the source code, I am not sure they are able to apply proper validation way in new technology because with the ASP.NET MVC app, I think they did not apply correctly or I don't think they understand the framework.
Any ideas why I should not use jQuery for MS's validation on a legacy app?
Thanks
Related
This question already has answers here:
Mixing Angular and ASP.NET MVC/Web api?
(4 answers)
Closed 5 years ago.
We are currently prototyping a new web-based product.
When we started the project we decided the technology stack would be based on Bootstrap 4, Angular 4 and ASP.Net MVC 5.
As we've progressed through the project we've found that we're not really using Bootstrap as other components (such as PrimeNG) appear to be easier to use and work better with Angular.
One big thing we've noticed - which is the point of this questions - is that we're not using ASP.Net MVC.
We have a Web API layer and all our mvc controller methods are simply calling web api methods and passing data through.
My question is this: Is there any point actually using MVC? I'm starting to think we could just have Angular talk direct to the web api layer as MVC is doing nothing for us in the middle.
Does anybody have any advice as to why I shouldn't do this?
No you don't need MVC at all. You can use any server language you like - either in the form of an API (probably easier) or another GUI framework like MVC.
As you've realised, Angular is just a client-side tool and doesn't care what the back-end is - it just makes HTTP requests and receives the responses, completely agnostic of the code which was used to generate those responses.
In fact, that's one of the beauties of the web - communication between browser and server is entirely done using agreed common standards (principally the HTTP protocol, supported by things like JSON), allowing an almost limitless combination of server- and client-side frameworks to work happily together so long as they both adhere to those standards.
You would use MVC in the case that you want the angular application to be server rendered and then served to the client. Other use case where you can force this is when you want the base code to be together and deployable from one project and not two, in the case that you have one project for webapi and another for the angular application.
In this last case, deploying two different projects will have the advantage that your angular app will be completely agnostic of you backend, this means that you just need to change the endpoints of your services and bam! Running app, no? Well not really, the contra is that you will need to configurate all the CORS related crap to it so that you client can communicate with your backend.
HTML helpers is the answer to your question(it really helps). Another advantage is that it provides better coupling with model and validation.
To clearly answer this one would need to understand how back-end works. You would need to understand how html-helpers connect with the backend and help bring in clarity in development. Also for testing purpose ASP.net MVC + Angular is a better option.
So this decision(to use MVC.Net) is unlikely to come from a UI developer but from an architect who has various challenges to answer.
1) conformity with front and backend(better communication/ isolated development)
2) improve code reuse
3) validation when and where (boundaries)
4) type safety
5) easiness in bringing in new developers
6) testability
What kind of framework is Razor? Is it backend or frontend?
What is the difference between the two types of frameworks?
I'm trying to learn a little bit more about backend and frontend frameworks and since I usually work with Visual Studio Asp.net MVC was wondering about it.
It is not a framework . I think you're misinterpreting certain concepts. Razor is a server side view engine, and it uses C # or VB.NET to generate dynamic content.
Razor Syntax Quick Reference
This question is a couple of years old, but I'm going to add my two cents.
People struggle to give an answer to this question because the terms 'front-end' and 'back-end' aren't formally defined anywhere. Because of that, any answer is purely subjective.
That being said, it is my opinion that the relationship between front-end/back-end and client-side/server-side isn't necessarily one-to-one
I think it helps to think of it like this: client-side and server-side are run-times, while front-end and back-end are a separation of concerns.
'Client-side' always refers to code executing on the client's machine and 'server-side' always refers to code executing on the server. A 'front-end' developer deals with displaying data to the user and getting data from the user, while a back-end developer deals with storing, manipulating, and retrieving that data.
Consider a front-end developer who is tasked with building a UI. Much of the code they write will be the typical HTML / CSS / JS. However, they will also have to deal with the data that is passed to the front-end from the backend. This is where Razor comes into play. The front-end developer will write the Razor code (which executes on the server-side) to display the data.
That is, the front-end developer will write server-side code to help generate the UI, in addition to writing the client-side code that really defines the UI.
Now, I can't imagine a scenario where a back-end developer will write client-side code.
So, to answer your question, Razor is a front-end technology that executes on the server-side runtime. It's only purpose is to generate the UI, which is the concern of the front-end.
Razor is for writing dynamic html page which is front end and c# is for writing backend logic. Although you could move all the backend logic inside razor but its highly not recommended.
Razor allows you on the back-end more easily create views (.cshtml in C#).
It is more like templating system...
http://www.asp.net/web-pages/overview/getting-started/introducing-razor-syntax-c
There is a need to have a calculator for our invoices which will be used both in the web UI and in the back-end. This requires two implementations of the same logic in Javascript and C# and the real problem is to keep these two logics in sync when it comes to changing the rules.
At the moment, what we do in the JS side is that we send all the requests for recalculations to the backend through ajax calls in order to use the calculator implemented in C#. This keeps our servers busy and I don't like the idea. I think that there should be a rule engine or something somewhere that we could utilise to keep the calculation logic in a language other than C# or JS and use/interpret it in both the front-end and the back-end.
Has anyone else faced the same problem? Any idea would be appreciated.
Faced the same problem and solved it by implementing the logic in javascript and then run it with https://jurassic.codeplex.com/ on the server. Works nicely.
You can try using Haxe to implement your rule engine and then cross-compile it to JavaScript and C#. This would give you a common implementation base for both and then - during compilation - your two different language outputs would be formed.
Disclaimer: I haven't used Haxe yet so I can't testify if it'd work for your situation but it supports both languages as targets.
You can use any decision-as-a-service platform. They usually expose decisions(bunch of connected business rules with relations and dependencies) as a REST API service. So you can simply interact with the service for execution and management of rules.
For example here is a sample how you can communicate with decision service for execution by passing input parameter values in JavaScript.
In the java world there is the bean validation framework JSR-303 which is a nicely well thought out strategy for performing data validation in both the presentation and persistence layers of an application. It covers a lot of things, including validation of whole graph models, validation domain grouping, i18n, etc.
I have failed to find any data model validation frameworks in C#. Are there anything similar to JSR-303 in C#?
You can try fluent validation:
http://fluentvalidation.codeplex.com/
There is the Enterprise Library Validation block.
http://msdn.microsoft.com/en-us/library/ff648831.aspx
It may not do some of the specific items you are asking about (i18n) out of the box, but it fits the bill for many other use cases.
Also, is free to use and has source code available.
On the front end:
The web side (asp.net) has Validation controls for web forms, and Validation Helpers for MVC. Both of these are smart enough to know how to render validation logic to the client page (for faster failure responses and reduced server load) and duplicate the necessary logic server-side (since you can't trust the client).
The Windows side has Error Providers for winforms. I'm not sure about WPF/Silverlight, or if there's anything for Console apps.
The result is that things are a little fragmented, but not so bad that you can't quickly find what you need. The idea is find the approach that's best for each platform, rather than shoehorning different platforms to the same set of principles.
On the back end, you can use the Enterprise Validation Application Block.
There is also the data annotations that can help with client and server side validation: http://msdn.microsoft.com/en-us/library/ee256141.aspx
So I am working on a personal MVC project for practice. I like the responsiveness with using ajax calls to web services to update the page and not have to do an entire post back.
My knowledge is very limited and I am only aware of being able to do this with Javascript.
However, from a new developer's perspective, there is one problem with this. It would be assumed that you would need to carry out this same behavior through most of your site for any of your CRUD operations on your domain objects. Therefore causing (again for a new developer) the lack of handholding with Javascript (debugging, unit testing, strong type...etc).
But do to my lack of knowledge, is there a way you can acquire this same behavoir in MVC without having to perform all your crud operations with javascript/ajax calls to web services?
NOTE: before beating me up about my loose remarks of Javascript....I like Javascript, and there might be ways to negate some of the points I made with using it for all your CRUD operations to get the behavior I seek that I might just not be aware of.
Based on your question, it sounds like you're looking for an UpdatePanel for MVC. This control isn't valid for ASP.NET MVC, but you could accomplish similar functionality by using AJAX (either the Microsoft.Ajax lib or something like jQuery) and returning a PartialView from your controller. There's a decent tutorial on this technique on Telerik's site (just ignore the parts where they render their own controls -- you could render pretty much anything).
If this doesn't met your needs, the I believe, in order to accomplish an AJAX-like behavior on your page or pages, there will have to be some degree of JavaScript involved.
You may want to consider using a JavaScript framework like jQuery or MooTools in order to wrap the AJAX calling behavior, so that you just have to invoke the already-tested AJAX calls (e.g. jQuery.ajax()). Your JavaScript, then, would just be the callback handlers to update your pages.
On the server side, since you're using MVC (which I'm assuming is ASP.NET MVC), your controllers could just return a JsonResult instead of a ActionResult and just have your CRUD operations inside your controller instead of create a separate suite of web/WCF services. (You could also return an ActionResult to your jQuery.ajax() call, too.)
So I don't think you're going to be able to get away from JavaScript in order to accomplish AJAX-style behavior in your web site. You may not have to create a suite of web services as you could just have them contained within your controller.
This is probably going to get you what you want. You may want to check out a tutorial on the ASP.NET web site for some additional insight (but that won't get you to the unit testing part of your question).