I'm starting a new project which in simple terms will have a UI layer based on asp.net mvc 2, a business layer and a data access layer. Simple 3-tier design.
The UI layer though will be customized for the client, e.g. menus along the top, or down the left or maybe different static pages, etc.
All the core features will be the same across the multiple clients but some clients may have more or less features available to them.
I'm thinking of using Areas in one single asp.net mvc project to separate the clients. So as I add clients I will add areas - is this a good approach? If I follow this approach can I share controllers? but have the controller route to the correct view within the area?
Also if I deploy my site to mynewsite.com - each area is going to be accessible at mynewsite.com/area1, mynewsite.com/area2 and so on. But if a client would like their own domain, what is the best way of achieving this? so that www.clientdomain.com -> mynewsite.com/area1 and clientdomain.com/products/list is the same as mynewsite.com/area1/products/list - would I have to handle this through the HTTP Url Routing on the server?
Hopefully I've explained my situation ok! Many thanks for any feedback.
Just for information - I decided against using areas in the end and I have simple client configuration component with custom view engine that I put together to swap out the views per client (using domain name and/or when the user logs in). The views are currently held in client specific folders and I only put the views I need to change for a client into those folders, if the view engine cannot find the view in the client specific folder it will revert back to the default views, which is pretty much the normal case as 90% of the client specific changes are done with CSS.
Related
I've been getting into isomorphic applications development with Angular 2 Universal but there is this thing that i cannot get clear in my head.
My understanding is that keeping back and front sides on different modules is a good practice, but it doesn't seem to be a common pattern when working with MEAN applications.
So, i am about to start a project that could scale and i'd want to implement the server side rendering in a future but i don't know which approach i should go with. Honestly i feel more comfortable keeping both backend and frontend on separate but, if so, will it be possible to implement server-side rendering later on?
Besides, supposing that i duplicate the index.html in both sides, will the server be able to delegate the control to the client when the first server rendering is completed? I mean, i can't imagine how that would that delegation work given the fact that they are not in the same project.
Thanks in advance.
As I understand, you are talking about rendering the UI and this is frontend part of your application, even if you do the pre-rendering work on the server.
This pre-rendering is only optimization, you can keep it in some separate code layer, but I believe that the whole idea of the isomorphic javascript is to re-use the same code on the client and server. This way trying to duplicate code and/or templates is not a good idea (it never is).
If you really want to keep things separated, think on splitting your application into more services:
backend server application - some kind of rest API on top of the database which holds all the business logic (first node.js application)
frontend server application - another node.js application which gets data from API via HTTP requests and does server-side pre-rendering (second node.js application)
frontend - all the code running in browser
This way, initially the "frontend server application" can be simple proxy between the "frontend" and "backend server application".
Later on you can extend it with server-side rendering.
Important note: if you are going to develop application without pre-rendering on the server and add this on a later stage, you need to take into account that not all the browser-side javascript features will work on the server (for example, manipulations with native DOM elements), see the best practices section in angular universal readme.
I'm building a WPF application using MVVM pattern, and Caliburn.Micro is the framework choice to boost up the development.
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer to handle logic for specific business cases. VM is left with data binding and simple conversion/presentation logic. Below BL is an extra Data Access layer (DAL) that encapsulates the Data model (DM) underneath built with Entity Framework.
I'm pretty new to both WPF, MVVM and, of course, know almost nothing about Caliburn. I have read plenty of questions and answers about the Caliburn usage and now trying to use what I've learnt so far in my application.
My questions are:
Does it sound okay with the above layered architecture?
In the application bootstrapper, is it correct that we can register all services that will later be used (like EventAgreggator (EA), WindowManager or extra security and validation services), and also all the concerned VMs? These should be injected into VM instances via constructors or so (supposed I'll be using SimpleContainer). So from any VM that are properly designed and instantiated, we can have these services ready to be used. If I understand correctly, Caliburn and its IoC maintain a kind of global state so that different VMs can use and share it.
Navigation: I know this topic has been discussed so many times. But just to be sure I'm doing the right way: There'd be a ShellViewModel acting as the main window for the whole application with different VMs (or screens) loaded dynamically. Each VM can inherit either Screen or ViewModelBase or NotifyChangedBase. When I'm in, let's say, VM A and want to switch to VM B. I'd from inside VM A send a message (using EA) to the ShellViewModel, saying that I want to change to B. ShellViewModel receives the message and reloads its CurrentViewModel property. What should be a proper data structure to maintain the list of VMs to be loaded? How can stuffs like Conductor or WindowManger come into the place?
Can/Should Caliburn in one way or another support the access to the database (via EF). Or this access should be exposed to VM and/or BL only?
Thanks a lot!
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer
That's the standard case. ViewModels can't/shouldn't contain business logic which is considered to be part of the Model (Model in MVVM is considered a layer, not an object or data structure) in the MVVM. ViewModel is for presentation logic only.
Yes, as long as your Business (Domain) Layer has no dependency on the DAL (no reference to it's assembly). Repository interfaces should be defined in the Business Layer, their implementations in the Data Access Layer.
Yes, Bootstrapper is where you build your object graph (configuration the IoC container).
Registering ViewModels: Depends on IoC framework. Some frameworks let you resolve unregistered types, as long as they are not abstract or interfaces (i.e. Unity). Not sure about Caliburn, haven't used it. If the IoC supports it, you don't need to register them.
One possible way to do it. I prefer navigation services though, works better for passing around parameters to views and windows that are not yet instantiated and you always know there is exactly one objects handling it.
With messages, there could be 0, 1 or many objects listening to it. Up to you
What do you mean with support access to the database? You can use it to inject your repositories and/or services into your ViewModels, other than that there isn't much DB related stuff to it.
Hi
I've been building the backend of my application (using nHibernate for data access).
So far i've had some simple web-services for manipulating my data, but now I'm required to develop a web UI on for my application (using web forms).
I've been looking at some different web frameworks (webformsMVP, spring.net web), and also at some client-side JS frameworks (knockout, angular), and I can't really decide what would be the best for me, and how to integrate it all.
I was hoping to get some insight from you guys.
I think I would like for my general workflow to be something like this:
View is created, calls its presenter.
Presenter contacts business layer to retrieve information (which in turn contacts DAO etc.)
Presenter returns a view-model object, which the view displays.
User manipulates data (maybe using some AJAX to retrieve further needed information)
View sends a view-model of the manipulated data back to presenter
Presenter translates the view-model into a model entity and sends it to business layer
now here are the parts that I find tricky:
A. How to map between view-model and model entities
I think I should use the entitie's ID to retrieve the unchanged entity from the DAO (which actually stores it in nHibernate's 2nd level cache), and perform changes on it.
(another option is to store the entity i'm currently editing in the user's session. but i'm afraid that this kind of caching would create duplicity with nHibernate's cache.)
B. How to translate changes on the view-model into changes on model entities
I'd like to have some logic when changing model entity's properties.
For example, for moving an employee from one department to another, I don't want to allow this-
department1.Employees.Remove(employee);
department2.Employees.Add(employee);
but rather this:
employee.MoveToDepartment(department2);
I'm afraid this could get complicated when translating from a view-model into a model.
Any thoughts on the above two questions, and also about any client-side / server side frameworks would be appriciated.
P.S. some quick background on my app:
-one page of the web app displays the company's structure (departments, divisions etc.) as a tree, and allows the user to click and edit the different nodes, as well as drag-and-drop nodes to change their location.
-another page displays current stock status (for each warehouse- how many products it has, how many machines are currently operative in that warehouse etc.)
- (some more pages which basically display data and allow editing...)
thanks
Jhonny
You can check out Automapper for your entity mapping. Alternatively you can write your own entity mappers and entity updaters. You can then encapsulate the business logic like Move To Department in your entity classes.
Your approach sounds just fine, and I can recommend Webforms.MVP as that is a good framework for writing testable WebForms apps without rolling your own implementation.
I am building a site in ASP.NET 4 and MVC2 that will have premium features, such as SMS notifications that will only be available to paid subscribers. I also have additional modules for things like Inventory, and Transactions etc
I am already leveraging the standard MembershipProvider, and am leaning towards using Roles tp provide this functionality.
ie: have an "SMSModule" role that the user gets if they pay for the add-on SMS service
This makes the controllers simple with a little attribute decoration, but the problem I see with this is that there will be a bunch of conditional code scattered through my views etc
Is there a better method of providing a "module" style approach in .NET 4 and MVC2???
You can add your conditional logic to view models, use the controllers to set the viewmodels appropriately and it should be fine... Sometimes you have to have the if statements inside the views even if not so ellegent. Unless of course you are using a view engine like spark then your if statements are placed in another unobtrusive location, but they still exist! You can always create HtmlHelpers and set the code to the serverside and based on the logic display appropriately...
FWIW I ended up using a combination of Descriptors in Spark View Engine, along with a custom Feature provider and associated ActionFilter
This seems like an elementary question, but after a lot of searching around I can't seem to find a straightforward explanation:
If I'm building a web application that is going to be accessed largely through a web browser, but that will also support some API requests in a RESTful way, should there be a large degree of separation between the two?
On one hand, it seems a large amount of the functionality is the same, with identical data presented in different views (HTML vs. XML/JSON). But on the other hand, there are certain things I need to present to the browser that doesn't quite fit a RESTful approach: how to get an empty form to create a new instance of a resource and how to get a pre-populated form to edit an existing resource.
Should these two different methods of accessing the system by funneled through different controllers? Different methods in the same controller? The exact same methods with a switch for view type?
Your core controllers don't have to change, but that doesn't mean you can't have some extra ones solely to support you UI. For example, both of the Form examples you have can be unique to the Web API. Your entry URIs can certainly have links to those pages for both the machine and user interface, just don't expect the machine users to actually use them.
Also, if your machine clients are simply XML/JSON, then those representations don't need those links at all to the forms, since they'll not use them, and they don't "work" in JSON/XML anyway. You can manage that through Content negotiation.