At my company we have a discussion as to in what way our future web applications should be build. We currently have 2 groups of developers who agree on several things. We all want to use html5 and css3 and jQuery. We mostly agree that web services will be very important.
However, one group advocates the use of mvc because it would add more structure? to the project. The other half (to which I admit I belong to), sees no reason not to consume the webservices directly from the client, forgoing mvc controller views etc.
To me adding mvc will only add another performance burden on the server that could be shifted to the client and structure could also be added to non mvc projects, though it might ask a little more effort from the developers.
At the risk of starting a flamewar. I would like to hear some arguments for either side from outside the company.
You are having the wrong discussion. HTML5, CSS and Javascript (and JQuery) are client side technologies. ASP.NET MVC is a server side technology. You still need code on the server that sends and retrieves data from the database. The next version of MVC (4, beta) will have Web API which is an excellent solution to create those webservices with.
Related
There is a project that is built using JSF with Spring Integration.
See https://www.tutorialspoint.com/jsf/jsf_spring_integration.htm to get an idea.
JSP is used for the html templates. Managed beans (part of JSF) make use of Spring beans as a managed property, which in turn drive business logic. The goal is to rip apart this project and split it into a RESTful service and Angular front end.
What is the best way to do this without re-writing everything. Which components can I get rid of, and which components can be re-used? If I use Spring Boot for building the REST API, can I re-use the Spring beans?
Edit: I am new to most of these technologies.
Exposing your domain model through REST should be relatively straight forward using Spring/JPA, whatever. You should learn about DTOs and especially as it relates to problems about "Lazy Initialization" under Hibernate/JPA/Spring Data, etc.
Secondarily understand the concept of views into the domain model. E.g., shipping looks at the database differently than marketing. Same database, different "facades" or business layers with different set of DTOs.
Conceptually, reproducing a JSF front end in Angular is something that is both "the same thing" and "completely different" at the same time. The key difference, IMHO, will be the JavaScript concepts and paradigms underlying Angular/React/Vue or whatever you want to use on the Front End.
Consider that an AngularJS/React/Vue front end might be better off running on top of node.js in a separate container or server, and might have different databases that it accesses on its own such as loyalty points or currency conversion, etc. Don't be afraid to let the frontend folks "be" the application instead of the backend folks. On the backend, try not to lose information. For example, if a customer adds 3 items, then changes 1, then places the order, that's 3 separate pieces of information, not 1 order. This is important for business analytics and customer service, which are business facing services as opposed to client facing services.
As a Java developer I tend to feel Angular/JS developers do a completely different and non-overlapping job than me. I feel the same way towards HTML/CSS folks. As such, I don't recommend you try being both, you will stretch yourself too thin. However, a good working knowledge on a smaller project, such as you are suggesting, is certainly useful.
Welcome to SO. Your post will probably be closed/ignored for being to broad, etc. Very specific questions and answers are what this site is about. GL.
I am trying to integrate spring-mvc and reactjs, but it's too poor example, but I like flux architect of reactjs so that i strongly want to integrate reactjs with springmvc!
I want to use reactjs as a client side, springmvc as a rest backend. Can you provide me some example or tutorial to do this? I've searched on google but it's very poor result. Please help me.
Thanks you very much
This answer might not be what you want, but I would advise you not to integrate the two of them. If they communicate over HTTP/WebSockets, they are already decoupled, and it might just cause you pain to couple them.
Advantages of decoupling the frontend and backend into separate projects:
People with experience only in React or Spring can contribute without getting confused by the other stuff.
The tooling/build you need for a Spring project is quite different from what you need for a frontend project, and mixing this into one code base can get pretty confusing.
If they're decoupled from the start, it gets easier to add other clients that use the backend API. By having them as separate projects, you're less likely to develop the backend in a way that's very tied to the frontend.
The frontend and the backend should use different versions and be shippable independently of each other. What if the backend team is currently doing a major refactoring, but the frontend team just fixed a critical bug and wants to ship a new release?
As soon as you add asset caching to your frontend project (like putting the files on a CDN, using the HTML5 application cache or the new Service Worker API), you have to prepared for getting requests to your backend from "old" clients. By separating them, it's easier to think about and plan for stuff like that on the backend.
I could probably list a couple of more benefits, but these are the ones I consider has the largest impact. There are of course some benefits of integrating the two of them, but those tend to get smaller and smaller as the project grows/matures.
There are number of REST frameworks around for ASP.NET MVC. Which one is the most mature in your opinion? Following are few I briefly looked at, but I couldn't decide.
Snooze
BistroMVC
Restful Service with WCF
OpenRasta
Siesta
REST support build in ASP.Net MVC SDK
.... there are few more.
Personally I would go with the default ASP.NET routing engine which is built and supported by Microsoft. This will ensure that you won't find yourself one day into the position of having to migrate some code which has become obsolete because the authors simply decided to abandon the project. Of course if there is something specific that you want to implement which isn't supported out of the box you could search for alternatives. But as far as exposing a RESTful API is concerned the routing engine should work just fine.
I completely agree with Darin.
But if you're looking for something closer to what WCF offers (Web service, versus a typical Web site), I've been extremely happy with WCF REST.
There's a WCF REST Service Template available via Visual Studio's Extension Manager that will get you up and running fairly quickly.
OpenRasta
Have been implementing RESTFul service using OR, only one word to describe it => "Pure Awesomeness" ....actually it's 2 words.
For me the simplicity is a plus, the framework is easy to use and adopt to. Some of it's conventions in my opinion really help me to understand Resful. Many integration points in the framework, very easy to extend its functionalists.
watching video recordings of seb's talk is very entertaining as well :) very opinionated (in a good way IMO)
I agree with Darin. Personally, I think Apache Thrift is also an option for doing client and server communication.
In the past I have primarily built all my web applications using an N-tier architecture, implementing the BLL and DAL layers. Recently, I have started doing some RoR development as well as looking into ASP.NET MVC.
I understand the differences between the different architectures(as referenced by some other SO posts), but I can't really think of any reasons why I wouldn't choose an MVC model going forward for a new project.
Is there any reasons/times in your experience when an MVC architecture would not be suitable, or any reasons why you would choose a BLL/DAL architecture instead?
I don't think your options are mutually exclusive. You could perfectly use MVC while using BLL/DAL for your model logic.
You can implement the M part of MVC as you prefer, there is no restriction about that. Using BLL and DAL would be a valid option.
For me? the only reason I'd not use MVC is because the application I'm working on was already started in web forms. I'm not a big proponent of scrap/rewrite, but anything new I do is in MVC.
One of the factors could be the statefulness of your web application. If it's a basic web application that gets everything from the server with a few JavaScript hooks such as client side validations, then the Rails type MVC is really great. I am not familiar with MVC on ASP.NET, but I've heard it's similar to that in Rails.
If the web application is really stateful, then a better approach would be to have a dual MVC layer - one on the client side, and the other for the server. The MVC on the server will mostly concern itself with authentication, authorization, churning out data in standard formats, etc. The client side MVC will concern itself with things such as DOM events, user actions, how they affect the application state, and how/when should data be requested/sent to the server.
MVC is just a way to organize code, just as BLL or DAL would do. MVC in Rails basically hides DAL altogether by using a set of conventions. Usually business logic resides in the models itself. However, if your application demands more complex BLL where object interactions can be intricate, then there's no reason why that BLL can't peacefully co-exist with the M in MVC.
I don't use MVC only on really tiny projects consisting of ~1-2 files and ~10-20 lines of code. And they will hardly evolve into something bigger.
But if they will, it will be time to rearchitect them into a MVC ones.
The only drawback we've had is that MVC pushes you toward a html/javascript interface where rich internet applications become more difficult. For example if you want to present the user with a calendar control, you may need to roll your own since you can't drop one on from the toolbox. That said, MVC is great. When we really need RIA applications we use MVVM and Silverlight.
For certain pages, MVC can be a little overkill:
splash pages
landing pages
marketing pages that are going to be thrown away after one use
one-off's
It's easy to get wrapped up creating a beautiful MVC architecture, when a small page, concisely written, can be OK on these situations.
MVC may also be impractical if you're in time trouble, and you need something out REALLY fast. Like your marketing team is out at a conference, they're having trouble, and needs something to show in their booth this second before they lose their biggest customer.
Life above the service tier suggests you should use the MVC pattern in a way that adheres to the SOFEA principles, and watch out for "Front controller" type frameworks disguising behind the MVC acronym.
(or, you can still use them, but at least read the article, understand the differences and choose wisely).
The simple answer is, no.
MVC is all around a better architecture than your old-school n-tier architecture, for many reasons. It's the standard approach in other UI models (e.g. Swing). The only reason it took so long to make it to web applications was because it took the software community, collectively, a little while to get used to the statelessness of the web and to be able to deal with the views and controllers in a way that made sense.
Personally, I would rate it based on the complexity of the target application. MVC (or more structured approaches in general) lend themselves very well to large scale applications where design consistency and segregation of code is a benefit outweighing the cost of supporting the design.
If its a small site, or very few pages/controls, I would avoid sticking to strict design patterns. But that is just my preference.
As one poster said, you also have to consider the state of any existing applications, and your development team skills / experience.
We have already use the MVC for the Windows application,Now we need to convert that thing in the Web application we don't have any problem in any thing. We are using the Web service and every Business Logic is in the Web service.
So you can use the MVC in the web application.
M-Model(Functions and Procedure which communicate with Business logic)
V-View(Design)
C-Controller(Form Logic)
so that is no connection in the DAL,BLL and in MVC.
you can define your Business logic and use in it any where in the MVC.
That's my point of view MVC is very useful for Re-usability i prefer if your application is big then you must use MVC.
I wouldn't use MVC pattern only in the case when I have an existing desktop application built with MVP and I have to convert it to a web environment. That's because I already have written logic for presenter.
In any other case I would use MVC.
You can refer to following
http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should-i-use-it.aspx
and http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080017 refer "Undisputable Facts".
I'm new to MVC structure and feel it's harder to get things done because it's a new way of doing things. Are there anybody who has experience of MVC vs. pages way of doing things. Is the MVC way of doing it the holy graal now or is there still value doing ordinary object-oriented development (or even procedural pages webdev)? Is MVC a fad?
A brief list of pros and cons for MVC
Pros
Testablily
Separation of Concerns - Promotes decoupling between major components
Helps you focus on one task/area at a time
Natural fit for Web and desktop interactions
Fits well with other design patterns, Single Responsibility
Principle etc.
Cons
Can require more code and effort
Can reduce clarity for simple pages (in these cases try to continue using simple pages)
Will take more learning
MVC is much more than a fad. It is a very pragmatic way of separating multiple concerns of a web application into manageable and reusable sections. Granted it does take some getting used to at first, but with some conscious effort at breaking your application up the MVC-style can be very rewarding. Often solutions are more succinct as they only need to concentrate on a single operation or task.
It is not a new idea either. It has been around in one form or another since 1979 (#Sarfraz Ahmed's link) and has been used in various web and desktop platforms.
If you are finding yourself having trouble using an MVC-style implementation then try to break it down into the individual parts or actions that are being used, and their corresponding area, model view or controller. As you probably expected, this will come easier over time.
Good luck
To MVC or not is mostly up to the needs of your project. Sometimes I have simple stuff that doesn't need the Model, but can still benefit from a controller/view arrangement. In those cases I might go with a micro-framework ( for PHP that would be limonade ) or even less. Still the majority of my web projects are MVC applications.
I started making websites around 1996-1997, everything was kind of new and there was no sense to what might be a good or bad idea in the long run. Around 2005 when I left the military and got back into web development it wasn't that enjoyable to fight through rat's nest of organically designed code. So When I was introduced to Ruby on Rails and the concept of MVC, I instantly recognized for myself that this was a game changer.
As MVC is increasingly adopted in more and more web projects, its paving the way for the next generations of developer's lives to be a little easier and more productive by providing common ground across companies and projects. Yes MVC is a little tough to swallow when going from the upfront simplicity of cooperative script to page projects but anything worth doing isn't going to be that easy right?
With all that said, if you get a good grounding in MVC in one language, it can provide a mental common ground for you to learn other languages. As for how long MVC will last as a dominant framework design pattern, the software industry is like a desert, everyday things change and great ideas become eclipsed by better ones (XHR for websockets, embedded objects for native audio/video tags) but I think whatever finally dethrones MVC will be somewhat similar because it doesn't really matter how great an idea is if only a very small portion of people understand it.
If we speak about ASP.NET MVC, the framework page itself has a discussion on this point:
The ASP.NET MVC framework offers the following advantages:
It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.
It does not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application.
It uses a Front Controller pattern that processes Web application requests through a single controller. This enables you to design an application that supports a rich routing infrastructure. For more information, see Front Controller on the MSDN Web site.
It provides better support for test-driven development (TDD).
It works well for Web applications that are supported by large teams of developers and Web designers who need a high degree of control over the application behavior.
The Web Forms-based framework offers the following advantages:
It supports an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web Forms-based application provides dozens of events that are supported in hundreds of server controls.
It uses a Page Controller pattern that adds functionality to individual pages. For more information, see Page Controller on the MSDN Web site.
It uses view state or server-based forms, which can make managing state information easier.
It works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.
In general, it is less complex for application development, because the components (the Page class, controls, and so on) are tightly integrated and usually require less code than the MVC model.
I think this exhaustive list provides answers to all your questions about MVC.
Since you have not mentioned language and if you mean mvc in php then this is also a great
resource for those new to mvc:
http://phpro.org/tutorials/Model-View-Controller-MVC.html
This is from a ASP.NET WinForms -> ASP.NET MVC perspective, however, ASP.NET MVC was the first time I heard of the MVC pattern (noob programmer) and I think if I discovered MVC in another language before ASP.NET MVC, I would've left ASP.NET/C# and went to that framework.
Learning and using MVC has made me a better programmer. I've always felt ASP.NET placed a transparent barrier between myself and the code (HTML or C#).
I've always wanted to break through that barrier, and MVC gives me complete control of everything in my app while emphasizing separation of concerns (something that makes coding infinitely more fun and less of a headache).
For me, MVC was the right choice.
The big advantage of MVC (in general) is that you are far less likely to create monolithic applications. You have a single request-act-response pathway, vs. something like ASP.NET webforms or JSF (although JSF is not as bad as webforms). It's very easy for a small site in webforms to become a big unmanageable tangled mess in webforms, then you have to start whipping out the custom controls and your team is lost. If you understand how the web work, MVC is easy ... although it is then in your hands to manage state.
After struggling with MVC for some time, I have to said that I now much prefer MVP (Model-view-presenter) architecture. Separation of concerns, decoupling and asynchronization are much easier to achieve with MVP than MVC, IMHO, because each MVC implementation doesn't split the concepts the same way, each controller doesn't handle the same things.