I am building a a web app with Spring MVC and hibernate. I am struggling with scope. E.g., create parent and children on same interface requires resetting child bean after first child created. Spring MVC does not allow removal of bean from session scope. At the same time, shifting children across multiple request scopes is not practical. I need a conversation scope.
I am now looking at Spring Web Flow as a solution. However, it is poorly documented and seems to depend entirely on xml configuration. Both these features seem to suggest it is an older and perhaps not well supported project.
Can anyone advise on whether I should invest time learning Spring Web Flow, or perhaps suggest alternative solutions that tie into Spring MVC.
I've spent some time on this now.
I think the reason for xml as opposed to annotation is design. Once one has one's head around it, the flow config is simple and leads to very fast development.
Yes, it seems to be in maintenance mode, but the design is solid and reliable and development seems to be very efficient. Learning curve is a little steep, especially if integrating into an extant webapp, but I was up and running in about three days.
Webflow's own documentation is not great, but the tutorial linked here is excellent.
UPDATE
5 months on and I have built a complete assessment system (i.e test/exam system). My background is in IT and I have a Ph.d in psychology.
The system I built has been thoroughly tested and stress tested.
Advantages of webflow.
A person can start a test, give up and restart in the same session with no problems since flowState takes care of everything
There is full control of when the user can use the back button and how far back the user can go. Returning to state after an illegitimate backbutton usage is easy and user friendly.
Stress test performance is excellent
Configuration is easy. I spent almost no time dealing with design or bug issues related to Webflow.
FRom a higher level design perspective, there were no use cases that were required from a business perspective that could not be implemented.
Disadvantages
Since all objects are serialized before presentation on the webpage, you have to be very careful about how you cache objects if you take them out of the flowState beans.
Spring Web Flow appears to be maintained, but not in active development. I see a handful of commits, mostly updating dependency versions and fixing bugs.
You are correct that the configuration of the flow is XML-only, which I believe is the single biggest drawback of this aging Spring project. I have searched for a DSL or dynamic builders and I did not find anything.
Having said that, I'd give it a shot. Simple flows—even dynamic and inherited flows—are possible. In addition, the backing form and the POST-Redirect-GET Pattern implementations may be useful to you. That last technique prevents form resubmission when you use the browser back button.
I have been looking at webflow myself (for the past day, ~16 hours) since after I seen "primefaces".
Webflow offers varying types of states and transitions to those states. States can have a view associated with it (HTML page or JSP page -> primefaces comes in here). Each JSP pages are templates, like PHP just using java and xhtml. Using primefaces components the interaction between the client and server "seems" almost automated (a plus for quick development). Webflow also offers flow variables, which is a java data object. The flow variable can have the life over the flow and is used by views and templates. Webflow allows you to control transitions between all states.
However, I think this is where I stop my research. First, what is the advantage of webflow over a good client side web application using AngularJS with Spring MVC (#RequestMapping), if flow control is needed build it on the client. If you would like a variable that exists over the lifetime of the session, make a javascript variable, however if the variable needs to only exist on the server and you would like to use templates, then webflow seems like a ideal choice.
If you need a state-ful webapp then it might be a good idea to checkout Spring HATEOAS type concept (passing the state as a parameter to the client), and that parameter refers to limited time availability variables. Less coding and seems to conform to internet model better.
Related
I prefer to keep my handlers free from ASP.NET infrastructure that is very hard to test (yes, even in ASP.NET Core). But sometimes it happens and you have a dependency like UserManager (I'd like to know one day why it's not an interface), HttpContext, etc. and unit-tests are turned into a mocking-hell.
I tried using integration testing to deal with it by creating a TestServer and having all the ASP.NET infrastructure initialized for every api call. It works quite well but sometimes seems like an overkill if I want to test simple logic of my handler. And while it solves technical problem of mocking ASP.NET infrastructure, it keeps architectural problem (if you consider it so) of having ASP.NET infrastructure into your handlers.
I'd like to know what are the recommended approaches to deal with it?
I feel your pain. I stumbled across a fantastic blog post from Jimmy Bogard that handles this problem by using what Martin Fowler calls Subcutaneous Tests. I will leave the deep explanation to those experts but in a nutshell subcutaneous tests simply avoid all the difficult to test aspects of the UI.
Shameless plug: I am currently in the process of writing up a wiki that demonstrates these patterns in a sample end-to-end project on github. It's not difficult to follow but is probably too much code to post for a SO answer.
To Summarize:
If you are using MediatR correctly your controllers should be very thin which makes testing them pointless.
What you want to test are your handlers.
However, you want to test your handlers as part of your real world pipeline.
To Solve:
Wrap the http request in a transaction.
Build a test fixture that mimics the applications Startup.cs
Setup a test db server to execute queries and commands against but also is reset after each test.
That's basically it. Everytime you run an integration test against one of your handlers:
The hosting environment is mocked but your application is started up in a real world test.
Your query or command is wrapped in a transaction mimicking your DbContext.
The handler is executed against a real database and then reset.
I would add more code examples to my answer but between the blog post and the wiki I provided, it is much easier to follow the code examples there.
Edit 8/2021:
Stick with the source. Jimmy Bogard keeps the contoso university project current on his github page. Another great and a little more advanced example is the modular monolith project by Kamil Grzybek. That also is updated regularly on his github page.
Mediatr or no, you should always try to have only very basic pass this along logic in your controllers and call injected business logic classes from there to do the actual work. As you inject them with interfaces to this business logic, your controllers' dependencies are easily mocked in your unit tests, and your tests can focus on if they implement those interfaces properly and do only the basic work of routing input/output. And your actual business logic can be tested even easier.
For those classes that are static, for instance for reading the web.config settings, one strategy that I like a lot is make an interfaced wrapper class around them. While ConfigurationManager is static, I can still just write a regular class with an interface that I put methods or properties on to read a specific setting (preferably semantically named) from the Configuration Manager. Now I can easily mock any configured setting (or absence of it) in my test by just mocking the interface and setting up different return values.
I'd say it depends on the level of confidence you want to get in the end. If you want to make sure the whole system works as expected, then integration tests using a TestServer are probably the way to go.
One advantage of MediatR, though, is it allows you to decouple your business logic from the application using it, which is why at the very top level, let's say in controllers, there's no logic but just a delegation to the mediator.
That being said, you're right that sometimes your logic needs information from the hosting application. An example would be the user making the request, which is accessible in the HTTP context.
In that case, if you want to avoid having to set up a test HTTP server to test your logic works, you could represent that information in an abstraction and your handler would then take a dependency on that abstraction. Your tests could then mock that dependency while using the real system for everything else.
Does that make sense?
We’re currently evaluating development with Sitecore 6 for a project. The client already bought it, so using another CMS isn't an option. The proposed setup would have Sitecore as our site’s content data provider; which would be consumed by a site built in ASP.Net MVC 3. We’d use Sitecore’s libraries to retrieve data from the Sitecore database on the server side.
In some cases, we also may want to consume content data via client side AJAX calls. I’ve been working on prototypes for this to see what data I can get back from a custom proxy service. This service calls GetOuterXml on the item, converts the Xml to JSON, and sends back the JSON to the calling script. So far, I’m finding using this method limiting; as it appears GetOuterXml only returns fields and values for fields that were set on the specific item, ignoring the template’s standard value fields and their default values for example. I tried Item.Fields.ReadAll(), still wouldn’t return the standard values. Also, there are circular references in the Item graph (item.Fields[0].Item.Fields[0]...); which has made serialization quite difficult without having to write something totally custom.
Needless to say, I've been running into many roadblocks on my path down this particular road and am definitely leaning toward doing things the Sitecore way. However, my team really wants to use MVC for this project; so before I push back on this, I feel its my responsibility to do some due diligence and reach out to the community to see if anyone else has tried this.
So my question is, as a Sitecore developer, have you ever used Sitecore as purely a content data provider on the client-side and/or server-side? If you have, have you encountered similar issues and were you able to resolve them? I know by using Sitecore in this way; you lose a lot of features such as content routing/aliasing, OMS, the rendering and layout engine; among other features. I’m not saying we’re definitely going down this path, we’re just at the R&D phase of using Sitecore and determining how it would best be utilized by our team and our development practices. Any constructive input is greatly appreciated.
Cheers,
Frank
I don't have experience with trying to use Sitecore solely as a data provider, but my first reaction to what you're suggesting is DON'T!
Sitecore offers extremely rich functionality which is directly integrated into ASP.Net and configured from within the Sitecore UI. Stripping that off and rebuilding it in MVC is lnot so much reinventing the wheel as reinventing the car.
I think that in 6.4 you can use some MVC alongside Sitecore, so you may be able to provide a sop to your colleagues with that.
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.
If you're in my position you have a big WebForms applications which have escalated to this unmaintainable thing. Things break when you add new features and you need an inexpensive maintainable way to do some kind of automated testing.
Now, from my understanding, the right thing to do would be to try building an abstraction layout of the page and user control model present in ASP.NET WebForms however, seeing as it would require a major investment in an existing application it is not an option.
I'm trying and pushing for a REST-like development as much as possible because it has some nice properties. And while doing this I've written a simple spider bot that crawls all URLs it can find and tries, simply getting them.
This allowed my to quickly find bad data that was causing problems and avoid having my end-users clicking on broken things, however, this is of course not enough.
I continued work on my crawler and it's developed into a simple REST client that tries different input combination, looking for a probable bug or crash. It's more intelligent that just an exhaustive search (because it knows about the ASP.NET WebForms application layer) and my goal here is to basically explore the state of the web application, hoping to hit all the corner cases before our users.
Does anyone have any experience doing something similar?
Also, for you test gurus out there. Is this a complete waste of time, or will I be able to actually say something about the quality here? From my perspective it seems to hit a sweet spot in that it will try things a potential end user would though a browser.
As I said before, we're stuck in a bad place. And we need a simple way out of it, right now.
We've tried things like Selenium, but it mandates a lot of extra work and we change things all the time, it's just no possible to maintain multiple selenium test suits for 50 different applications.
Of all the types of testing to implement, unit testing is both the easiest and the most likely to yield results, in terms of less bugs and more maintainable code. Get that worked out before you deal with automated integration testing
Pick an IOC Container - I like Ninject for this personally
Find a convenient place to inject "service" classes into your Page (the consturctor of a base Page class or override the module that loads pages, whatever works for you)
Pick a unit test framework and if you don't have an automated build then set one up; include running a full suite of unit tests in that build
Every time you go near a piece of logic in an aspx.cs file, see if you can't isolate it in a service and wrap unit tests around it
Take a look at whether the MVP Pattern would be good for you - we found it decreased productivity as much as it increased testability (it did both a lot), but it works for some people
See about slowly migrating your app over to MVC, a page at a time if necessary
And remember, you are not going to fix this problem overnight, you don't have time. Just keep improving test coverage and you'll see the benefits over time.
What part of your application is breaking? The UI, or the business logic?
Business logic should be completely separated from the user interface, and should be tested separately. In particular, it's much easier to use automated unit testing tools against separated business logic than it is against UI.
If i am rigth you have a large web form and want to run some standard end user tests each time you do a new release.
I can recomend the Selenium IDE adon for firefox.
it will allow you to record your user actions, e.g filling in a form, and allow you to replay those actions at any time. an easy way to run some test over a form with differnt data.
For internal code testing write some Unit tests using NUnit
I'm thinking about going into the ASP.NET MVC scene.
I've seen the videos at http://asp.net/learn, but they havn't impressed me.
So can you answer me, what makes MVC "so impressive", and why does it make life better and easier?
ASP.NET MVC is much more in tune with the technology on which it is layered. ASP.NET Forms attempted to pretend that there was a nice fat stateful infrastucture as there is in a standard WinForms app. However HTTP and Web servers do not like fat stateful applications.
ASP.NET MVC allows for a separation of concerns. The request is processed by a controller not a "Web Page", it chooses how to respond and what UI is needed to present that response. The controller builds the set of structured data needed by its choice of view then hands over that data to the view.
This division allows much easier testing, the view is merely a means to present what should be a complete well munged chunk of data. Its way easier to build a test for something which takes structured data in and responds with structured data.
ASP.NET Forms is almost impossible to test in this way (especially without expensive tools claiming to achieve it). Hence an MVC application is easier to get right and much easier to ensure it stays right by consistently running existing tests.
Caveat: The major draw back of ASP.NET MVC right now is lack of solid documentation. I've been assured that docs are coming "soon".
Have you ever worked on a large project that had great intentions when it started but 3 years later was a complete mess?
MVC is a just pattern it can be misused the same as ASP.NET is misused. It is just harder to do.
Model–View–Controller (MVC) is an
architectural pattern used in software
engineering. Successful use of the
pattern isolates business logic from
user interface considerations,
resulting in an application where it
is easier to modify either the visual
appearance of the application or the
underlying business rules without
affecting the other.
It allows you to separate your logic in a way that makes sense to most people. While at the same time it lends itself well to testing.