I may be searching on the wrong keywords, but I'm having a hard time finding a suitable solution for the following case. We have an internal application that has five separate business areas within the application. In the past, this has all been set-up inside a web site project, and we've piece meal deployed changes to this environment. We've always had issues with one change bringing down the entire site.
In order to mitigate this while also bringing easier ways to unit test and potentially get into continuous integration use cases, I would love to have a structure where all the transactions for particular business areas (domains) stay within their own separate project. The architecture may look something like:
Main Project (Houses authentication, base master page, styles)
Ordering (Houses all things ordering)
Models/Views/Controllers
Pricing (Houses all things pricing)
Models/Views/Controllers
My question is how do I incorporate all this and give myself the ability to deploy each project separately at any time I'd like. So, for instance, I make updates to the Ordering domain, compile it, then upload the project without affecting the other domains.
Obvious other questions revolve around routing. How do I get the route correct? I'm assuming there are ways within the RouteConfig to set namespacing? What's the solution for this?
Is this what MEF does?
Have a look at Areas:
The MVC pattern separates the model (data) logic of an application
from its presentation logic and business logic. In ASP.NET MVC, this
logical separation is also implemented physically in the project
structure, where controllers and views are kept in folders that use
naming conventions to define relationships. This structure supports
the needs of most Web applications.
However, some applications can have a large number of controllers, and
each controller can be associated with several views. For these types
of applications, the default ASP.NET MVC project structure can become
unwieldy.
To accommodate large projects, ASP.NET MVC lets you partition Web
applications into smaller units that are referred to as areas. Areas
provide a way to separate a large MVC Web application into smaller
functional groupings. An area is effectively an MVC structure inside
an application. An application could contain several MVC structures
(areas).
(from MSDN, linked above)
Which would give you the logical separation, but not the functional.
To deploy Ordering without potentially taking down Pricing, the easiest thing to do would be to have separate web applications (which can be hosted within a single site if that's a requirement) for each. You can extract any shared logic to a class library project and reference that in both front ends.
Related
I have a huge monolith application, a ASP.NET MVC Framework service offering ~50 different "groups" of unrelated data, separated into 50 different controllers/business logics. I was tasked into breaking this monolith into 50 microservices (each one hosted in Docker containers).
What I'm planning to do is to create a "template application" using ASP.NET Core to serve as a reference project and, for each of those 50 applications, I will fork this "template" project, add the corresponding controller with the necessary business logic and may need or not to customize this template to add some specific features.
For example, one application may need to respond to requests using a CSV format instead of the JSON, which is the standard for ~45 apps. So, I would modify the "template project" to include this "CSV response" feature and it would be used by the other ~4 projects that would use it.
What I can see currently:
PROS
Developing a ASP.NET Core application is easy, but it requires some configurations and customizations (CORS, Cache, routes, etc.) that would be already defined into "my company template" project.
CONS
Forking and merging the template project can be troublesome. If we find a security issue in the template, it would be necessary to manually update all of the 50 projects and fix some potential merge conflicts.
Is there another option available in ASP.NET Core to make this "template" project easier for updates and maintenance? Or a design pattern for this?
Just use a class library. Common functionality and even base controllers and such can all go there and be referenced by the actual API projects. Your common config can be added to the class library as IServiceCollection extensions:
public static class IServiceCollectionExtensions
{
public static IServiceCollection AddMyCors(this IServiceCollection services)
{
services.AddCors(...);
return services;
}
...
}
Then, any change to this library automatically propagates to your APIs because of the direct reference.
However, bear in mind, that pretty much the entire point of microservices is loose-coupling. You should really only share this kind of functionality for things that are relatively static and won't change. Making changes that requires every single one of 50 services to be updated, pretty much defeats the entire point.
If there's too much common, shared functionality, you have to ask yourself if you've truly decomposed the services into subdomains. A very common mistake in this way is not realizing that the actual data should be segregated as well. Ideally, each microservice should have its own data store (database, for example). If you are trying to make the microservices share the same data store, then you will inevitably end up with significant cross-over and it will be difficult if not impossible to segregate their domains. That means you loose niceties like foreign keys sometimes and you may need to even incur some data duplication. That's where CQRS, event sourcing, and other related patterns start to come into play.
I've read a lot on this topic, but cannot find out a clear answer on how to structure a complex project around symfony2...
My new project will be structured with :
1) one back office website hosted on a subdomain of our partner's website
2) one partner's website
3) one (or more) customer's website
Of course, each of these websites will share logics from "core" bundles (i.e : core entities, core user logic, etc...), but they also need to have custom routing, custom templates, and so on...
I think that I have 2 options :
1) define 1 bundle per website and define routing based on the hostname, but it seems that it is not recommended
2) implement one SF2 instance by website, and copy/deploy core bundles into each instances
What is the best solution ? And is there another solution on how to implement some kind of complex project?
It's difficult to say which is best for your particular situation: I've used both approaches for projects. I actually have one project which uses both approaches simultaneously, consisting of two Symfony applications: One generating the main website, the other generating a separate application containing some other functionality, with separate bundles for the "user" functionality and the "admin" functionality. We used Varnish to dispatch requests to the correct application, based on the URL path.
In my experience I've found that having multiple applications adds a degree of complexity to the overall solution. This makes it more complicated to work with and to hold the "big picture" of the whole system in your head. There's also potentially a cost implication, if you want to run your applications on separate servers. You also need to consider that there's overhead on getting the whole solution set up for local development, which is definitely a concern if you're in a team of more than one.
The flip-side of this is that working on one part of the whole solution (i.e. one app) is often more straightforward: Configuration values/dependencies for the other applications won't need to be set up, you only need to get working the bare minimum for that one standalone app. This approach also affords you a lot of flexibility and the ability to concentrate changes on one particular area of the solution. For example: If you wanted to make some changes to the partner's website, if that was generated by a completely separate application, it becomes straightforward to do this. You know that there won't be knock-on effects to your other applications. This goes for shared code too, providing you version it correctly: With composer, your separate applications can depend on different versions of your shared bundles/libraries if necessary. Another benefit of having separate applications is the ability to scale them independently of each other. If your customer website gets much more traffic than your partner's site, you can set it up on better hardware/virtualised instances, giving you finer grained control over performance/costs.
Sharing code is relatively straightforward with Composer and is not one of the main concerns here, in my opinion: Think carefully about the above factors when making your decision.
I'm looking to create a new MVC site, and one of the key problems I'm trying to solve is sharing code between a public area (web-facing) and an internal area.
Basically we have two applications, one that is the public web site that users access, and another that will be used internally at our company to view some of the same information that is also visible on the public site.
I would want to keep them as two separate sites (projects) because we have different teams of people working on each, and because we want to use different authentication formats (Forms for the public, Windows for the internal).
However, we also want to be able to share some of the code (views, controllers) between the two sites. How could we set up these two MVC sites such that one MVC site could reference a view and / or controller in another project?
For instance, we will have a view that will enable internal users to see transaction history of our public site users. If we have created that controller/view in the internal site and later we wanted to add the in the public site, how could we re-use this same view on the public site?
Technically, as others have already said, you can put everything you want shared in a class library project, and then reference this project from your other projects. Views are a bit different as, in order to share them between projects, you will have to compile them. You'll need Razor Generator for that.
Practically, though, it's going to be rare that a view should be shared between projects (aside from something like a layout), and virtually non-existent that you should share a controller. If the overlap is that great, it's an argument that the two projects should not in fact be two projects, but one. Controllers and views are so customized to the application that sharing them just doesn't make sense most of the time. It is however a very good idea to share your models and other classes.
2 approaches I can think of:
First option is to use MVC Area. It gives you different controller/view for each area, while sharing the same Model. You can also encapsulate common methods in a Helper class.
Second option, create 3 projects. One is a .NET library containing the common logic, Models, validations, sending emails etc. Then create 2 more MVC projects, one for each site, and reference the project.
Look at using Areas within your site (this would allow you to keep the projects independent, but together as one final solution). Also, look at compiling your views in another library so you can share them between projects.
Some references:
Compiling views in MVC
See also RazorGenerator
MVC pluggable modules
I am asp.net MVC beginner and I have just created new solution. What I have noticed is that there is now an option of adding two projects under the same solution, and that is something that is new to me.
What is a main purpose that one should add multiple project under same solution?
A solution can hold multiple projects that are related and logically grouped together. For example, a solution may contain two web site projects (a user site and an administration site) and then also a class library project that they both share which contains common database access code or business logic.
Usually we separate our code into multiple projects for easier maintenance in future. On an high level we make separate Class libraries for Data Access, Domain Models, Business Logic. Web project for Front end UI. This way we are physically separating code, that it increases re-usability. Say in future you want to re-use your Data Access components, then build that class library and take the DLL and use it in other projects.
Also in future if you want to replace a certain layer, then you can simply decouple it and change, without changing any other components of code.
This physical segregation of code with Logical Dependency Injection would give you more cleaner, easy to maintain, re-usable, loosely coupled systems
I've looked all over the web for the best way to organize an ASP.NET MVC2 project. I've only seen examples of people using the default template for MVC2 projects. But is this the best way to organize your project if it is going to contain a large number of files?
We're in the process of building an application that is heavily built around jQuery for UI and ajax using JSON. So, as you can imagine, we will have many custom .js support scripts.
In our solution, we have placed all our support libraries (3rd party and custom) into respective projects. The MVC2 project that is also in the solution is using the default MVC2 template.
In the MVC2 project, the "starting" structure is still pretty much unchanged. Under the Controllers directory, we have each controller AccountController.cs and HomeController.cs (for example). Under the Views directory, we have three subdirectories named Account, Home, and Shared. In the Scripts, directory we have also divided that up with three directories, Account, Home, and Shared. And finally we have the Models directory, that is also divided into Account, Home, and Shared subdirectories.
As you can see we haven't deviated from the basic template that much. But, as we start adding stuff to this, we're realizing how cumbersome this might become when we get upwards to 20 or 30 views and 100 support .js files.
Any suggestions would be great!
Thanks.
Look into using Areas to organize your Views/Controllers/Models/Content.
Here's a good article from Microsoft: Walkthrough: Organizing an ASP.NET MVC Application using Areas
To accommodate large projects, ASP.NET MVC lets you partition Web applications into smaller units that are referred to as areas. Areas provide a way to separate a large MVC Web application into smaller functional groupings. An area is effectively an MVC structure inside an application. An application could contain several MVC structures (areas).