I'm creating a website for a company which has 3 different firms. The domain hence will have 3 sub-domains like this:
www.example.com
firm1.example.com <-> www.example.com/firm1
firm2.example.com <-> www.example.com/firm2
firm3.example.com <-> www.example.com/firm3
The firms will not share code between each other. Each firm has its own db hosted on the same server. Each firm will have a link to main page ie, www.example.com.
I decided to create one module for each firm and a main module which will be called from main.dart. Now how and when do I call the second module. While doing so, I'm not understanding the necessity of having a module over controller.
Is this right to modularize the app in this scenario?
What are the advantages of having multiple modules?
Should we use one router for each module? The reason I ask this is that in the future if I plan to remove firm3 and put it in a separate domain which will no longer be sticking to the main application, then I will have to remove the corresponding routes from the router which is unlikely for a modularized app.
A module is for combining a group of type registrations for the injector. Usually you also have several modules even when you have only one company.
Have a look at this example: https://github.com/akserg/angular.dart.ui/blob/master/lib/carousel/carousel.dart
This is a Carousel component which consists of two components which are always used together and which depends on the TransitionModule.
The CarouselModule allows you to register all those types with just install(new CarouselModule);
A module has nothing to do with program logic, it is more for registering a group of Angular components, directives, services, ... at once.
A controller is all about program logic.
What are the differences between these three companies?
You could create three different apps and move the code you want to reuse between these apps in a package and import this package from these three apps.
Update
If the 3 apps share no code it doesn't make any sense to put them in one application.
You can use virtual directories functionality of the web server you are using.
What you get is a dependency between applications that have otherwise nothing in common (besides being served from the same server).
You have to cope with code size. Each user loads the code for 3 apps even though he wants and can only use 1/3 of this.
In Dart it is not so easy to load code on demand (at least not yet).
Summary: Your approach has no advantage and serius disadvantages. Create three independent apps instead.
Modules are not the same thing as Controllers. A module holds all of the parts of your application. That includes Controllers, Services, Directives, etc. A Controller is only one thing that belongs to a Module. A Module not only holds parts of your application, but it also allows each of the pieces to find each other. Modules are the basis of dependency injection.
So you have 3 different firms within a single company. Are those firms apart of the same domain? Are they separate websites or a single website? If each firm has their own domain or separate websites you will have no choice but to separate them into separate angular apps. A single page application cannot span multiple domains.
If you are defining routers per module then you're looking having separate applications. You can define 3 separate modules and import them into a Main application, but the Main application would define the router. I'm not entirely sure you can have multiple routers per app in separate modules. I can't find any examples of that. In theory maybe, but it seems like it would be difficult to maintain.
But only given what we know it's hard to make any more recommendations because how the 3 firms interact isn't really known. Will they share code? Do they have to be all in a single page application or can you split them into separate html pages each with their own angular app?
Updated:
So I would separate each firm into their own App with their own router. I would make them each a separate single page app. You can choose to share code or not. My application consists of multiple single page apps and I share code between them. Here is how I do it:
var RegistrationApp = angular.module("RegistrationApp", ["ngResource",'ui.bootstrap',"ngRoute", "ngAnimate"]);
var App = RegistrationApp;
Then in any other type of thing I define I use the global variable App like so:
App.factory("RegistrationService", function($http) {
By having the global variable App defined in all of my applications that I build I can share code simply by including those components in with the app the client is loading and it'll pull in that code into that App's module.
Login will be something the server side does and it will drop a cookie on your browser so each app technically could use that authentication provided the cooke maps to the domain. If you have separate URLs for each firm (ie firm1.company.com, firm2.company.com, firm3.company.com) you have to be careful how that cookie is defined because by default if you login under say www.company.com that cookie will not be seen by firm1,firm2,firm3 because those are different domains. You'll have to set a cookie for .company.com so subdomains can see it. But if you do it right login won't require communication between firms/Apps.
I think the easiest would be to manage that at webserver level.
If I understood well, you have 4 independent sites:
www.example.com
firm1.example.com
firm2.example.com
firm3.example.com
I you are using Apache, that would mean different 4 virtual hosts. Then, you just need to redirect www.example.com/firmN to firmN.example.com using, for instance, .htaccess.
Alseo, security-wise, this method allows to have the data of each company in a separate container, if once you have an attack in one site, you don't want the attacker to have access to all the other sites.
Related
VS2013 update 4, MVC5
Still relatively new to MVC. To divide functional domains within an MVC project the use of Areas seems clear from these posts (olderSOlink, newerMVC5link).
Is there ever a reason that sub-domains would be integrated as part of a solution involving different functional domains of a given MVC project? I don't have a reason to want to make use of sub-domains, I'm just asking because I don't know if there is some advantage I should know about.
Is it even possible without great difficulty? For example, can logons transfer across sub-domains? Would there be other difficult issues to address?
At present the project I am building is 'relatively' small and will have around 5 major domains so I'm assuming Areas is the best architecture to isolate these domains, but I wanted to ask for guidance before I go too far and make decisions that would make the use of sub-domains difficult in the event there is a compelling reason to use them in a single MVC project.
I generally use subdomains to separate major application functionality or if I have multiple servers that I want to be on the same domain name.
To answer your login question, if you are using the same application you will remain logged in on the whole domain (depending on your method of using sessions, the cookie will be accessible to the domain as a whole).
If you are questioning using subdomains, they are really just a naming scheme so you could categorize your 5 major applications into one domain with different paths (eg. /portal, /store, /etc..) then later you could point store.domain.com -> domain.com/store. So it's pretty flexible in the end.
I would like your guidance on this.
I'm trying to build a website that has two "players" (which, I assume can be translated to "roles"?). One player is "consumer" and the second player is "supplier".
Both are interacting through mutual (sql server) database.
Now I would like to have totally separate systems each player, with totally different authentication mechanisms.
However, I would like to have the consumers system as sub-domain of the main domain, i.e., I would like to have the consumer system under 'mydomain.com', and the suppliers system under 'supplier.mydomain.com'.
However, I can't figure out how to technically do this? Can I create another web project in my solution, call it 'suppliers' and let it include all the features of the suppliers system?
Or should I create separate controllers for the suppliers features inside the main project?
The first option sounds most "clean" to me, however, how can I route the user from the main (the consumers) website to the suppliers website based on the subdomain?
If I choose the second option, how can I make sure that user which authenticated as customer will not be able to perform as supplier?
This is probably very common task to do, any good tutorial or example for this?
You will create two separate IIS applications - one for your consumers and another for your suppliers.
You will then set the host headers on each to your required domain and subdomain. IIS will then take care of routing URLs to your separate applications. Instructions for setting IIS host headers here https://technet.microsoft.com/en-us/library/cc753195.aspx
As for managing application code, given you want complete separation I would suggest creating three Visual Studio projects:
Web application for consumers
Web application for suppliers
Class library of shared code - database logic etc
You are then able to develop and deploy each web application independently.
In terms of tutorials, there is quite a lot available, here are a few which will help you:
https://web.archive.org/web/20211020150710/https://www.4guysfromrolla.com/articles/122403-1.aspx
https://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/
https://softwareengineering.stackexchange.com/questions/207101/managing-multiple-projects-that-share-code-customization
for this problem, so use "Area" =
https://msdn.microsoft.com/pt-br/library/ee671793(v=vs.100).aspx
Consider an MVC4/EF5 project:
Creating a web application which will have 3 modules.
Based on the customer license, we will enable or disable 1-3 of the modules.
Each of the modules will deal with a handful of common tables (Users, Company, etc).
Each of the modules will deal with tables specific to their functionality (PO's, Timesheets, etc)
An admin portal, admin users in a seperate table from regular users.
data passed to views using view models
eventually there will be a JSON service for exposing parts of the applications functionality.
There will be multiple deployments of this application with slight customization (beyond just enabling/disabling each of the three modules).
The Plan so far:
Separate dll for Model
Separate dll for each Module/Functional area.
Separate dll for the ViewModels
Separate dll for admin portal
Seperate dll for the web service
Questions:
Is anything gained by a seperate dll for ViewModels?
Tips for managing multiple variations of the same application, with regards to project organization, and source control?
Should there be a separate dll for authentication (membership and role providers)?
Any other thoughts? (Sorry for the open ended/loaded question, maybe I should remove this one)
My advice:
Don't try to solve your problems with Source Control. Unless you are
really good with branching/merging and very very disciplined. I'd
recommend one code base that is pulled together with Di/IoC
DI/IoC lots and lots of it - Look at Autofac and the Mutli-tenancy
extra. Keep everything loosely coupled as much as possible
Testing - TDD as everything needs to be loosely coupled lots of testing - look at Autofixture/AutoMoq
Extension points galore - layers of re-direction are your friend as
everyone will want different implemenations. Our core architectural elements
is a CQRS light style - Commands, Command Validators, Queries, and
Domain Events
Keep everyone on the same database structure (unless you go NoSQL
etc)
Use Onion Architecture - Make 3 projects, Web
(MVC5/WebAPI/ViewModels), Infrastructure (all the technical stuff
Repository implemenations etc), Domain Layer
Then make projects per client with overrides - e.g. Custom
ITimeSheetCalculator etc
Include ViewModels in Web Project - Look at per tenant ViewModel
mappings if required. Use AutoMapper
Look at stuff like VirtualPathProvider EmbeddedVirtualPath provider
so you can put views CSS in client DLL
Create an Ambient Configuration file that defines what is turned on per tenant. Feature toggles will be required. Especially during dev for features not yet complete
Find yourself a canary - a client you can work with on a beta version who you trust and can give good feedback
For security look at using Claims Based Identity - comes baked into MVC5. Makes it easier to have different security rules pre tenant etc
If you are working with multiple clients and they all want different
features/or same feature but implemented differently you need get the strongest person you can get to gather requirements. You can't do traditional Scrum and have developers etc and work directly with all the clients. You need someone in your company acting as proxy product owner who will take ownership of the problem of getting all clients to agree on general features
Consider Azure has lots of nice features we have used. Easily allows scale up and down.
Good luck
Whats your best practice (within MVC) with how you work with front-end-developers and back-end-developers?
Take this example: The team of 3 (1 front-end and 3 back-end) have 10 modules to develop on a homepage. All modules require HTML, CSS, Images as well as controllers and models.
How would you usally set up your workflow?
If I as a front-end-developer design a module without a proper controller and model, how do I best work with dummie-variables? Best to not use variables and just put "lorem ipsum" in my views? Or should I create a temp-model with set values to not have to edit the view after the back-end-developers are done?
Is it better as a front-end-developer to wait until you have all the modules and controllers you need OR maybe work at the same time on a homepage module?
Thanks for sharing!
For me backend is the domain and the service layer which comes in a separate assembly. Frontend is Controllers, ViewModels and Views. So backend developers start by defining the model objects and service interfaces and provide the frontend developers with this assembly. They could also provide a dummy implementation of the service interface which simply returns hardcoded values. So the frontend developers could now start designing the controllers which would consume the services, map the domain models to their corresponding view models and pass them to the views. Once the backend developers have finished implementing the service interfaces they provide the frontend developers with the new version of the assembly and the frontend developers simply switch their DI framework to point to the new implementation instead of the dummy one.
You could also have some frontend developers working on a reusable framework of HTML helpers, extension methods, ... which will be used all along the project.
My workflow goes as follow:
Back-end developers creates views using proper XHTML markups, without high styling. They are making only mockup.
Front-end developers creates CSS classes, styles, etc.
When Back-end developers have finished their work and Front-end developers have all styles done, then it's time to merge. All styles are applied to mockups, and some corrections are applied.
I'm wondering what you think of the several methods there are to accomplish this:
Use symlinks for the shared files
Create a gem/plugin that provides the shared files and code
Create a web service that pulls views/partials from the required app and stores it in a cache
My objective is to reduce complexity in a large application. Let's say I want to build an online community, and I want one app to handle forums, another to handle user galleries, etc., and a central one which manages users and provides common views to the other apps.
So, the master application would have to provide a common layout and widgets to all others, and each app would need to provide some views to the master app too.
For example, say the layout has a main menu with an item for each app, and each item has an over-sized sub-menu, so I can't just have a simple list of label and URL pairs.
So perhaps the master app would ask each child app to provide its menu item and contents through a private API, build the menu, save the output in a cache, and send the full menu to each app when asked.
As you can see, I'm already leaning towards option 3, but I wanted some feedback on my approach and if maybe there's a better way.
Thanks for your input.
From what you describe it really sounds like you should be using a single Rails application. The view interdependency makes me think that you might benefit from this approach. I also imagine that testing will be more difficult because your 'application' will span three actual Rails applications.
That said, if you are set on using three applications, I would recommend against using and API. APIs are great for passing data (json, xml...) back and forth, but they aren't as well suited to views. My recommendation would be to create a plugin of common views that could be stored in a separate git repository and simply used within each of your applications. That way the common code is shared amongst the applications yet still locally accessible to all of them.