I need to create/publish a complex MVC site to several clients, each with mostly shared functionality but also custom stuff, such as client specific controllers / views / business logic etc. Most insist on hosting the site themselves, and have functionality they don't want others to know about.
Following reading this SO post and this, I've created a means for MVC Multi-tenancy, which seems to handle most scenarios.
As I can't attach to Stack Overflow, I have posted it here (no need to read it all - it's mostly screenshots!).
The basis is to have a generic project, referenced by several client projects. The client project can then have a similar structure to the generic and take precedence when I wish to use overriding code/controls/views.
As it's the foundation of the whole thing, I don’t want to implement something only to find everyone else does it in an easier/ better way.
My question is a bit wooly, but simple - Is there a better way?
Your architecture seems about right. I would just say that you have to be really careful about the generic thing and how the client's addons will talk to the core application.
I would do that by having a base project in the CVS with client's specific branchs referencing it (as in git submodule) so everyone can beenfit from the core.
Rolling out production and QA versions are also something that must be dealt with caution as you can end up with different version far from each other depending on the client.
Related
I am wondering about how should i implement certain things. I am new to the Microservices architecture, but i think i understood how it works in a certain way. But i am very confused in the shared code, and shared projects thing.
I am developing a new system which contains about 50 microservice including ApiGateWays as well. I am working only in ASP.net Core
I want to standardize the requests and responses. I created a new project which contians only models, so no logic included, just a few interface and some classes.
Is it hurting the core principals of microservice architecture any ways?
I know in a certain point it does, but i develop only in ASP.Net core, and it is a very basic no logic model collection, which standard in the whole system, so if i would create a node.js project then i would use the same model there as well.
The other thing is the HealthCheck middleware. I am thinking to create this in a shared project and i would just reference it from the microservices. This would contain logic, so i am confused, i think that if i would copy and paste it to everywhere than it would not be better than creating a shared project for it. It must be a standard thing, so if i have to change it for some reason then i would have to change it every single microservice as well.
What do you think about this? It is a good practice to do it? I know this is not the best practice, i know if i would work in a team i won't try to use the HealthCheck in a shared project, because that would cause more issues than it would solve, because which team should develop that and so on...
And the last thing, somebody can help me to understand this whole code sharing in microservices, if it is possible, i read a lot of articles about it, but everybody says that you can share, but you should avoid it. Please help me if you have time for it, i think a lot of newbie how jumps into microservices, and developing alone has this confusion in his mind.
Thanks for your time and i hope this would help some newbie in Microservices, which has the same confusion in Sharing code between microservices
In the microservices world, there will still be a need for shared libraries. Healthchecks is one of them.
On MSDN docs this is described in detail.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-3.1
A healthchecks shared library would that use that code and provide ways for your micriservices to register healthcheck endpoints with a call of one extension method.
Also that way the endpoints registered would be the same for all microservices.
Tell me if you need more info and I elaborate more.
I have a fairly high level design question. I'd like to come up with a framework for creating multiple very similar ASP.NET MVC sites.
These sites would be for selling various consumer goods, with each goods category having its own site (this requirement is fixed). Different category sites would mostly be quite similar - essentially a series of static pages that allow drilling down into various subcategories to view product listings, with some simple forms for expressing interest in a listing (for example).
However, it's vague at this point exactly how similar these sites might be, so I need a degree of flexibility
I come from a React background- so my vague initial thought is that the best way to approach this would be creating a library of common components used across the sites - these would range from fairly low level ones for, for example, a table of specifications, to higher level ones that might cover an entire page. The library consumer could pass in the specific apis used for the components/other specific data. I don't have much experience with the ASP.NET MVC framework, so I'm not yet certain exactly how that would work.
My question is: does this sound like I'm on the right track with this approach?
Any alternate suggestions? Also, are there any particular ASP.NET MVC features that would be key to an approach like this? (Not sure yet whether I'd use the older .NET Framework MVC, or .NET Core- any features of either that would favor one or the other for this?)
Thanks so much for your time, I appreciate the help!
There's frankly all kinds of ways to do this, and you may choose one, some, or all. For common classes (entities, helpers, etc.) you can create class library projects. You can also share controller code this way as well. Making smart use of generics will allow you reuse greater amounts of code. Sharing views is a bit more complicated, but there are ways to do that, such as RazorGenerator or NuGet packages. NuGet packages should be used to share static resources, as well, such as images, JavaScript, stylesheets, etc. Alternatively, you can host these on a CDN or other centralized area and reference them from there (use configuration to set path/URL, so you don't hardcode static paths all over the place).
As far as framework choice goes, ASP.NET Core provide a bit more than MVC in the code reuse category. You can create custom middleware, view components, tag helpers, etc. ASP.NET MVC has somewhat similar capabilities (HTTP modules, child actions, and HTML helpers), but it's arguably a bit more difficult to reuse those components/create them in the first place. Other than that, though, choice of framework really doesn't matter.
As the Definition of MVC, what you say that "creating a library of common components used across the sites" are content in the model and controller part. MVC has nothing special from other OOP approaches, but just specify that you are going to divide your abstract classes into three different category: Model (which define the container of data), View (which define the appearance of the program) and Controller (which define the behaviour of the program).
MVC is just a pattern but not a technology. For example one of the web-application I worked on in the company, the MVC structure followed as: ExtJs frontend (it has it's own controller written in javascript to call our API, therefore all itself could already be called as a "MVC" program), C# API server backend which linked back to our database (both Oracle and Microsoft SQL). As you can see, all of these components can be replaced by something else (for instance, you can use Angular2 replace ExtJs, you can use java or php replace the C# API server, and so on).
I am new to MVVMCross (and MVVM in general). I would like some architectural advice before I start coding.
I am porting a couple legacy applications. They share a large amount of business logic. I was going to expose this logic as a service. My questions (so far):
Is there a correct way of doing this that I don't know about yet?
If I place the interface/implementation classes in a separate project outside of either Application's core library, and reference it from both core projects will the DI still locate the service?
Similarly if the service needs to publish messsages (eg errors), will the framework handle this?
Platform specific code - my understanding is that platform specific code should go into the View project (not fond of this idea), but how would this externally located service implement platform specific code?
I think you might be able to get some advice from:
the wiki in https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control and in the - e.g. see the section on plugins there and see the example code for assemblies other than Core.
the N=31 walkthrough - http://slodge.blogspot.co.uk/2013/06/n31-injection-platform-specific.html
Specific answers:
Sounds reasonable - but this is just just c# so you can use any C# code pattern you want to.
Yes - see example in the wiki - https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control
It's up to you to provide your own error routing and handling - there are examples available - e.g. http://slodge.blogspot.co.uk/2012/05/one-pattern-for-error-handling-in.html and Display Error or Information from ViewModel to View - but this is just C# code
One idea is to build "plugins" - see https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control (and there's an N+1 video on this too in http://mvvmcross.wordpress.com)
I have a specific case and I want to know the best practice way to handle it.
I make a specific .NET framework (web application). This web application acts like a platform or framework to many other web applications through the following methodology :
We create our dependent web applications (classes for the project business, rdlc reports) in a separate solutions then build them.
After that we add references to the resulted dll in the framework.
And create set of user controls (one for each dependent web application) and put them in a folder in the framework it self.
It works fine but any modification to a specific user control or any modification to any one of the dependent web applications. We have to add the references again and publish the whole framework !!
What I want to do is make those different web applications and the framework loosely coupled. So I could publish the framework one and only one and any modifications to the user controls or the different web applications just publish the updated part rather than the whole framework .
How to refactor my code so I can do this?
The most important thing is :
Never publish the whole framework if the change in any dependent application, just publish the updated part belongs to this application .
If loose coupling is what you are after, develop your "framework(web application)" to function as a WCF web service. Your client applications will pass requests to your web services and receive standard responses in the form of predefined objects.
If you take this route, I recommend that you implement an additional step: Do not use the objects passed to your client applications directly in your client code. Instead, create versions of these web service objects local to each client application and upon receiving your web service response objects, map them to their local counterparts. I tend to implement this with a facade project in my client solution. The facade handles all calls to my various web services, and does the mapping between client and service objects automatically with each call. It is very convenient.
The reason for this is that the day that you decide to modify the objects that your web service serves, you only have to change the mapping algorithms in your client applications... the internal code of each client solution remains unchanged. Do not underestimate how much work this can save you!
Developing WCF web services is quite a large subject. If you are interested, a book that I recommend is Programming WCF Services. It offers a pretty good introduction to WCF development for those who come from a .NET background.
I totally agree with levib, but I also have some tips:
As an alternative to WCF (with its crazy configuration needs), I would recommend ServiceStack. Like WCF it lets you receive requests and return responses in the form of predefined objects, but with NO code generation and minimal configuration. It supports all kinds of response formats, such as JSON, XML, JSV and CSV. This makes it much easier to consume from f.ex. JavaScript and even mobile apps. It even has binaries for MonoTouch and Mono for Android! It is also highly testable and blazing fast!
A great tool for the mapping part of your code is AutoMapper, it lets you set up all your mappings in a single place and map from one object type to another by calling a simple method.
Check them out! :)
Decades of experience says: avoid the framework and you won't have a problem to solve.
Frameworks evolve like cancer. The road to hell is paved with good intentions, and a good portion of those good intentions are embodied in a colossal tumour of a framework all in the name of potential re-use that never really happens.
Get some experience and knowledge when it comes to OO and design, and you'll find endless solutions to your technical problem, such as facades, and mementos, and what have you, but they are not solutions to your real problem.
Another thing, if you are using MS technology, don't bother with anything beyond what .NET offers. Stick with what the MS gods offer because as soon as you digress and become committed to some inhouse framework, your days are numbered.
I'm maintaining an application which currently is just a web service (built with WCF) and a database backend. The web service is built in layers with a linq-to-sql data access part with core functionality in an own assembly and on top of that the web service assembly which contains the WCF code. The core assembly also handles all business logic rules (very few actually).
The customer now wants a Web interface for the application instead of just accessing it through other applications which are consuming the web service. I'm quite lost on modern web application design, so I would like some advice on what architecture and frameworks to use for the web application. The web application will be using the same core assembly with business rules and the linq-to-sql data access layer as the web service.
Some concepts I've thought about are:
ASP.NET MVC (or MVC-2)
Webforms
AJAX controls - possibly leting the AJAX controls access the existing web service through JSON.
Are there any more concepts I should look into? Which one is the best for a fresh project?
The development tools are Visual Studio 2008 Team Edition for Developers targeting .NET 3.5. An upgrade to Visual Studio 2010 Premium (or maybe even Ultimate) is possible if it gives any benefits.
Definitely dig into ASP.NET MVC2.
All of our projects are now being developed using ASP.NET MVC2. It's not just highly scalable. It's highly testable as well. Which leads to way better maintainable apps in the long term.
WebForms vs. MVC2 points - (speaking out of experience):
Scalability:
In our company we had a lot of applications using WebForms which then were updated and changed by us as needed by our customers.
I think your customer will be requesting more changes on the application in near future. Making calls to other services, and maybe you'll have to rework parts of the final product to match their wishes.
And with the upcoming Cloud Computing and the Windows Azure platform you'll probably need to keep up with your code.
ASP.NET MVC absolutely supports the concept of being able to scale up your application any time you want.
I remember one of our customers walking up on me asking me for an extension for their app (they have a member management system) and the feature would contain something like a link to export the current view as a csv file so they could do office stuff with it (mostly serial letters).
It wasn't really a big problem setting that feature up. (took around 2 hours including writing tests) - let's go to tests:
Testability:
Using WebForms we didn't really have much interest writing tests because it was a pure pain to do so.
I remember writing some tests to have at least some proofs but let's drop that topic.. (:p)
We had tests for our custom classes but we couldn't really test all the EventHandlers within the WebForms.
Our CodeBase is way cleaner and saver to use thanks to this testable environment. I just check out some of the code, modify it, run all the tests and: Oh, it broke on strange behavior! - Let's fix that again. Earlier, I remember sitting with my co-worker debugging and trying to find those bugs for hours.
With ASP.NET MVC2 we are now lacking tests!
We ask all kinds of people (even the non-Web ones) to provide test-cases we could feed into our TestSuite.
And yeah, there are some AJAX-Controls too:
AJAXability:
You asked about AJAX Controls and in conjunction with ASP.NET MVC I highly recommend you to check out Telerik ASP.NET MVC UI Controls.
If that isn't something for you, we also make extensive use of jQuery and jQuery UI
With ASP.NET MVC and the HTML Views, those libraries aren't just a pleasure to use, they just look amazingly beautiful.
There is no random-html-tag-id-value autogeneration anymore!
But what I like most is: You can finally really re-use your code again.
There is so much more to those frameworks than just that, there is the T4 templating system. Auto-Scaffolding for your ViewModels / DomainModels with the Html.EditorFor() method and of course there is a great and easy way to use the IoC and DI paradigms.
Assuming that you have asked the question with mostly .NET Framework related tags, you'll probably stick with it.
Just to keep the post complete, there are also other frameworks that are just as good (or even better):
Ruby on Rails
Django
CakePHP
And many many more!
There's also DynamicData which may be appropriate if you need simple CRUD access to your data.
The Web Service Software Factory (WSSF) might come in handy in your situation.
This will allow you to define your contracts (XML entity returned (if XML you choose), etc.) while designing the server/client communication using WCF (or standard Web Service communication protocol).
WSSF favors either ASP.NET MVC or ASP.NET MVP. A simple example of the MVP architecture is shown here, plus this article.
As for me, I often come with a hybrid-like architecture using a bit of both MVC and MVP, as both have different strong points which combined together fill each other's improvement points.
I'd also recommend looking into Silverlight.
http://www.silverlight.net/learn/
Just my opinion to use MVC on Client sites and WebForms inside administration pages(site)