This is question about MVC web-app architecture, and how it can be extended
to handle componentizing moderately complex units of functionality.
I have an MVC style web-app with a customer facing credit card charge page.
I've been asked to allow the admins to enter credit card payments as well,
for times when credit cards are taken over the phone.
The customer facing credit card charge section of the website is currently
it's own controller, with approximately 3 pages and a login. That controller
is responsible for:
Customer login credential authentication
Credit card data collection
Calling a library to do the actual charge.
reporting the results to the user.
I would like to extract the card data collection pages into a component of
some kind so that I can easily reuse the code on the admin side of the app.
Right now my components are limited to single "view" pages with PHP style
embedded Perl code.
This is a simple, custom MVC framework written in Perl. Right now, controllers
are called directly from the framework to service web requests. My idea is to
allow controllers to be called from other controllers, so that I can componentize
more complex functionality.
For simplicity I think I prefer composition over inheritance, even though it will
require writing a bunch of pass-through methods (actions). Being Perl, I could in
theory do multiple inheritance.
I'm wondering if anyone with experience in other MVC web frameworks can comment
on how this sort of thing is usually done.
Thank you.
Create a component (class?) which wraps all the cc specific functionality, and expose it through appropriate methods/functions.
Use composition to provide your controllers, both customer and admin facing, an instance of the cc component, and have both call the appropriate methods to achieve what needs to happen.
I have dealt with something similar many times, and I absolutely prefer keeping my "controllers" (or any other code that depends directly on third party libraries for that matter) as "stupid" as possible, and do like you said - pass through anything that calls for functionality that's specific to your app. This keeps my code easy to test, which is what drives most of my design these days.
I hope we're talking about the same things, MVC can be applied at so many different levels it sometimes gets confusing.
Related
I want to make a REST services based application and I have no ideas to start with. Do you have any suggestions?
I know what REST services are and how to implement them, but I don't have an idea for what application to do.
Probably the most standard REST example or case study is a content management system. ie a system where the main resources are "documents" (/documents/1 /documents/2 etc). It could also be "posts" for a blog or "tweets" etc.
You can then enhance it with a separate resource for authors, add policies for reading and writing posts, and so on.
The good thing about this model is there's no real business logic or API scraping to implement, and it's easy to test by checking document contents.
Of course, the best projects to use, when you have the luxury of choosing them, are always those you have a passion for developing.
We are currently on Kentico EMS V.7 but when our site(s) was created there was not any mobile device layouts setup. an out entire site is build around ASPX+Portal templates so we don't have the edit layout option on our pages. What would you recommend an origination like ours do in this case? Is there an import or migration tool that can be used to move the pages into a responsive design template (are these available out of the box or do they all need to be built?)
has anyone else come against this challenge with their site when trying to a mobile accessible site, if so what approach did you take to move your site(s) over?
I know Stackoverflow doesn't like to answer broad questions, but I'll save you some trouble and hopefully at least point you in the right direction. I use to be in your shoes and I remember how frustrating it was trying to find resources to learn all of this.
You've got some options, but unfortunately none of them are magic bullets. All of these options involve design and development time. If you haven't already done the research to consider if optimizing your site for mobile users is a good business decision, then I would suggest starting there first.
Mobile Device Detection
Kentico offers device layouts that allow you to change the layout of your site depending on which device a user is browsing your site with. The technique it uses is called device detection, which relies on reading the incoming user agent string of the user's http request on your server and using that information to determine what to send back to the user's browser.
This process happens on the server side of your application and also relies on comparing the user agent string against a list of known user agent strings. Kentico in particular uses the 51degrees library to accomplish this. This has the drawback of not always having the most up-to-date user agent strings, so new devices won't be included in your list unless you keep it updated.
A big problem with this approach is that you wind up maintaining multiple sites and/or layouts. If you uses Kentico's mobile device detection, then any time you need to make changes to a page template you will also have to change each of the different layouts for that template.
You don't have to utilize Kentico's device layouts functionality to do mobile device detection. You could just redirect users to a different site entirely. In which case you can still very easily run into the problem of redundant maintenance.
Yes, there are ways of mitigating these issues, but most web devs agree that responsive design is usually the way to go if you want to cater to mobile users.
Responsive Design
This is a client-side design paradigm that relies on CSS media queries. I'm not going to explain how it works since googling "responsive design" will net you plenty of research material. The short version is your user's browser handles the adjustment of the layout by interpreting the CSS of your site. This means you maintain one CSS file for one site and the client handles the adjustments for you.
Now the down side to this is that it takes a takes a talented web designer to do it properly. There are many responsive frameworks out there that can help you out with this, but their appearance is pretty generic and will likely still require customization to fit your particular brand requirements. Some more popular ones are bootstrap, semantic-ui, and foundation.
I recently helped convert a large website in Kentico with a static design into a responsive design by rebuilding all of the page templates using Bootstrap and merging their stylesheets together so that the desktop version still looked the same and the mobile versions had a consistent appearance with the desktop version. This process took about two months and required a lot of UX and content strategy in addition to visual design and coding skills to accomplish correctly. It's not the hardest job in the world, but requires quite a bit of skill and time to do.
In my humble opinion there is no tool which will make (magically) your site responsive. AFAIK the only way is to redesign your site manually (new CSSs - maybe any UI framework, JS etc...)
Maybe you can still use out of the box features like device profiles and mobile pages. (But I am not sure how it works and if it is supported while using ASPX + Portal templates development models).
I am using an PHP MVC framework (Yii, but my question could apply to most MVC frameworks) to create a project that should include a web application (website) and RESTful web service. I am facing an early design decision on how to logically separate the application and service logic. Here are some true facts:
The web app and web service will share a lot of functionality and only differ in rendered format (View vs JSON)...
...But, the web app and web service will have some unique features (ie, there will be things that the web app does that the service does not, and vice-versa)
Here are my desires:
I would like to share the common functionality's implementation as much as possible
I do not want the Controller to become unwieldy as a result of combining web service/web application logic
I have a a slight distaste for creating separate web service and web app controllers, especially when they overlap in Actions (other than the rendered format)
I do not want to have the web site consume the web service unless it is really a necessary design decision; I will lose out on a lot of built-in features that use database interfaces and/or have to create classes that conform to available IDataSource and other such interfaces by hooking it up to the web service; also there could be a slight performance decline.
I have thought about it a bit and come up with some solutions below. Please let me know which of these you think would meet my wants or let me know if my wants are not reasonable/counter-productive.
Implement completely separate controllers for WebApp and WebService (modularize the two so that they share no code)
Implement separate controllers for WebApp and WebService, but create methods that do the heavy lifting and call those methods to share implementation - for example, if I wanted to do a item/findBySomeCrazyCriteria I would route to the appropriate controller depending on the URL, but each controller would reference some FindItemsBySomeCrazyCriteriaFunction() defined elsewhere.
Make the web app consume the web service (which would require me to expand the planned functionality of the service)
Implement one controller for both WebApp and WebService, which extends from a BaseController that includes generic hooks for REST type stuff in terms of $this->getModel()` and use overrides where necessary
Anything else
Although my question is related to Yii, I feel like this must have come up in the past for many developers. I would like to know what you did/what you recommend to move forward. I am concerned that if I choose the wrong approach I will "break MVC" or somehow regret it later.
Note: you should not worry about "breaking the MVC". Since you have chosen to use Yii, that part has already happened.
The root of the problem lays in the fact that your controllers do a lot of stuff (and thus, violating SRP). What you call "controllers' actually contain also the application logic (that should be part of model layer) and UI logic (that normally would be part of view instances).
What you should have there is a single application, with one model layer and two presentations (what you refer to as "web application" and "web service"). The controllers should be a slight a possible.
You should move the application logic to the service layer through which then the presentation layer would interact with model. You would end up with a lot lighter controller. Then you could be able to provide a separate set of controllers/view for each of the presentations that your project needs with no or minor code duplication.
I would recommend against writing multiple controllers. It is a much better option to keep your domain logic in the models, rather than controllers. Your controllers should only act as the gateway to the logic and serve them in whatever form the client requests eg. as a JSON encoded response or through a view. It would be best if you just keep the task of identifying the client requirements and after obtaining the results from the model translating the response in an appropriate form.
This flow can be streamlined with suitable helpers and a well implemented routing sub-system so that detection of client requirements becomes effortless.
eg. /user/subscriptions.html will fetch an html page where as /user/subscriptions.json will fetch a JSON response.
I'm currently developing a web application, that relies heavily on mobile and desktop clients consulting the web server for information. This can be accomplished nicely making a RESTful API available to handle this. So my idea is to have an application acting as the "platform" which handles all the real business logic and database information behind the curtains.
My plan is to make the platform using symfony2 and OAuth 2.0 authentication mechanisms, combined with RESTful web services.
Now my real dilema comes on the website component. Ideally I would like to think of the website as yet another client that asks this REST platform for information, and completely separate it from the platform itself.
To make it a little bit more clear, let's say we are making a blog with this architecture, so one would have a "platform/backend" that provides a rest service to list articles, for example: /articles/5. This on the backend, and with symfony2/doctrine means that the app has an Article model class, and these can be requested from the DB. A simple controller queries for the Article number 5 and returns all the information in JSON format.
Now the website on this example, could just do the easy thing and also have an Article entity and just query the database directly, but I think it would be cleaner if it could just talk to the platform through it's REST api and use that information as a "backend" for the entities.
So the real question would be, is there anyway to support this kind of design using symfony2? Have entities rely on a REST api for CRUD operations? Or I'm just better off making the platform/website a single thing and share a "CoreBundle" with all the generic entities?
There is nothing in Symfony that prevents you from doing you want.
On the client side you could use Backbone.js or Spine.js.
Have a look at FosRestBundle, it makes your life much easier to create api:
https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/doc/index.md
In web frameworks like ruby on rails, any database queries needed to handle a specific request happen before a page is passed to the client in a controller class, but there's nothing like that for clojure. Where should database queries and stuff like that be handled in a clojure web app? My gut tells me to call a function within a hiccup page and generate the HTML within that function, but I'm not really sure. Thank you for your time and consideration.
There aren't that many "full stack" web frameworks in Clojure and as far as I know most Clojure web applications aren't built with one. There is a collection of frameworks and tools that handle a variety of things, but you'll likely develop your application using these components as building blocks. You have a choice of routing functions, authentication, view rendering, templating, RESTful web services and persistence.
Where particular things should go in your application depends on your architecture - a typical, 3-tier MVC web application looks different from a full blown scalable app that's using CQRS, CEP and other fancy patterns that help you build the next Facebook or Twitter.
If you design your web app conceptually with a 3-tier MVC architecture in mind, you'll have a clear separation between your view layer, business logic, and persistence layer. Like Alex said in his answer - it's probably the Controller that ties these things together. If you don't have complex business logic, your controller will likely call functions from your persistence layer directly before passing it on to the logic that builds your views.
For some situations, it might be useful to pull in data from your persistence layer in a "middleware" — that is a function that gets called by Ring every time a request comes in. This could be the stored information about a logged in user for example.
A number of options for your building blocks: Mature Clojure web frameworks?
Most (all?) of Clojure's routing/request handling frameworks are built on top of Ring. An overview of what that looks like is here: http://brehaut.net/blog/2011/ring_introduction
IMO, whichever code generates your views should call the function, and use the result of the function to dictate how to render the view. Looked at from the Clojure perspective, Controllers could be seen as functions that are called by the router.