I've been doing some research on DI (Unity and Ninject) for a multi-tenant ASP.Net MVC 4 application. Most articles I've read seem to refer to DI as a good tool to help provide customizations to the tenants in a multu-tenant web application. Other than that what else is it useful for within the Multitenant world.
Can it help with data isolation in share db schema scenario? I'm trying to find a clean way to isolate data between customers. (I'm using tenantId in all tables where needed)
(ASP.Net MVC4, Entity Framework 5, SQL Server 2012)
IMHO, as far as the data isolation is concerned in a multi-tenant application using a shared schema, I don't foresee any use of a DI Container as it just helps resolve object dependencies. It is up to you to have the security control mechanisms and tenant isolation practices in your application that filters the data based on the operating tenant or the contextual tenant.
You have to carry forward the tenant identifier from the presentation tier throughout the other layers till the data base access. It is in the access logic where you will be filtering the data based on the tenant, this can be done using the tenant identifier in the tables.
Also, in a single code base approach there will be no requirement for injecting dependencies to identify tenant. The tenant identification and validation the operating user and his tenant context will be done by your application during authentication and authorization phase itself.
Hope this addresses your query
Related
My client requirement is to implement application as same application with different database as Multi Tenant application.
As per requirement, different user can access same application but as per user identity he will be connecting to different database to access company specific details. each company has different database.
I would be planning this with Asp.Net MVC, EntitiyFramework with database first (as database already exist) but I am not sure will able to handle this as multitenant app. Can you please guide or give me any direction or sample if already implemented.
Thanks
Nik
I am launching my startup and i need to make a critical architecture choice.
I will provide a SAAS web application for my clients, they have different specific needs but the main purpose of the program is the same, automatically generating documents and pdf.
Technincally i choose ASP.NET MVC, WebAPI, EF Code First. Now I have a working proof of concept with only one project (1 db, 1 asp.net mvc client, 1 asp.net webapi, 1service layer + 1 repository)
I will have one database for every client (easier to maintain, scale ...)
One WebFront for each client with personalized html/css templates and of course specific data/menu
Only one WebApi service exposing all services for each client,
For example /api/client1/, /api/client2/ with almost the same api calls but not the same data returned.
For each client a service layer (Class library dll) that stores business logic, data acess, POCO/DTO.
Each Webfront shares reference to specific service DTO/POCO.
I need of course my solution to scale horizontally, not vertically.
So is it a good choice?
Do you have any recommendation/better solution ?
Can I put All this in the same visual project ?
I really would like to have the service layer(business) in only one project, and with good Object Oriented approach I can serve all my clients with common needs shared between all of them and specific one in derived objects.
Thanks for help
I have already done a proof where I can include Node.JS within an ASP.NET MVC application.
Assume that I am going to use an external session provider like windows server appfabric Cache or memcache.
I have an application where there is a quite sophisticated assembly that we use to build middle tier objects that we then store in the session. The assembly and the objects it produces is our most valuable piece and I cannot justify rewriting this C# project into something this is more Node.JS friendly.
This data is stored in an external cache, and now the node.JS developers need access to that.
What techniques have you guys used in situations like this? I am pretty sure that I am going to have to have some sort of service interface provide by the asp.net side as it is the one that owns this system of record.
I am also looking for a green field option for new projects that allow both ASP.NET MVC and Node.Js work together well in a hybrid fashion anyway, so perhaps this could be solved by data being stored in a convention that works for both.
Thanks.
I wouldn't use ASP.NET session at all. Maybe a database would be a more interoperable approach. SQL Server or even NoSQL solution such as RavenDB might be a good choice.
The problem with ASP.NET out-of-proc session state providers is that they use non-interoperable serializers (such as BinaryFormatter or NetDataContractSerializer) so you cannot read the data back from NodeJs. There might even be differences in the serialization mechanism between the different versions of the .NET framework so even with 2 ASP.NET applications running on different versions of the framework it might be a challenge to share session data.
I am building a new applications architecture and I need your advice. We have a central MSSQL server database hosted as SQL Azure. This database needs to be accessed from many different applications, most of them are web applications hosted in windows azure and couple of them are winforms apps.
Accessing database for web application is straight forward with ADO.Net. For winforms applications, the wcf data services technology seems impressive along with client authentication services for security.
I need to know whether this mixed mode of database access will work? In other words, will database integrity will be maintained if it is being hit by applications using a mix of ADO.Net and Entity framework.
Thanks in advance.
If you query the database using EntityFramework it will cache the data until you call SaveChanges(). If the database is modified (e.g. using plain old ADO.NET) in the meantime there is a risk of the data from the database being overriden by the application that is using Entity Framework. To prevent from this you need to use Concurrency Token. You can find some details here: http://social.technet.microsoft.com/wiki/contents/articles/3866.aspx
Note that when you start using concurrency tokens you need to be aware of possible concurrency exceptions which you need to handle. You can take a look at this blog post http://blogs.msdn.com/b/rickandy/archive/2011/02/17/handling-optimistic-concurrency-exception-with-ef-and-mvc-3.aspx for some ideas. WCF Data Services uses ETags for concurrency (http://blogs.msdn.com/b/astoriateam/archive/2008/04/22/optimistic-concurrency-data-services.aspx) but you may not need to do anything here if you setup concurrency in the EF model for the database that is exposed via WCF Data Services.
We are going with WCF RIA services. They seem to work well with multiple client types providing out of the box data access layer.
For ASP.NET MVC extranet applications, what are the pros and cons of using SQL Authentication instead of the ASP.NET Membership API to handle security?
Gern, you are describing aspects of the same framework.
The asp.net provider stack is an abstract service layer that 'provides' common services to your applications.
The built in Sql providers are simply implementations that use Sql server as a backing store. The MVC framework and scaffolding provide all of the necessary adapters for using the default Sql providers.
If the built-in asp.net sql providers provide the functionality you require then the pro is that all the work is done.
Not sure what a con would be.
In regards to the possibility that you want to compare using Sql providers vs AD providers:
The AD/Token based providers Active Directory for authentication and access control and the implication is that a user must have a valid account setup in the AD in order to access protected resources.
The Sql providers allow you to define arbitrary users that do not require AD accounts.
The infamous grey zone appears when you have a large AD user base that you must support but must also allow for non-AD accounts to be established. At that point you will start to explore the exquisite joy that building composite provider stacks will bring to your life while it steals your sleep. But that is a topic for another book.
HTH