If a singleton is created once per application, you can probably guess that a tenant-singleton is created once per tenant.
So when might you need this scope? Think of any object that is expensive to create or needs to maintain state yet should be isolated for each tenant. Good examples would be NHibernate's Session Factory, RavenDB's Document Store or ASP.NET's Memory Cache.
I don’t know how this happened but for the last couple years (at least), whenever I read an author who writes about ORMs, I often see a sentiment like this: “ORMs are fine, just make sure you disable this pesky feature called Lazy Loading”.
It’s like this feature is not even needed and only brings confusion and performance issues to everyone who chooses to use it. Well, as you may guess from the title of this article, I disagree with this point of view completely.
public interface ICustomerUniquenessChecker
{
bool IsUnique(Customer customer);
} public Customer(string email, string name, ICustomerUniquenessChecker customerUniquenessChecker)
{
this.Email = email;
this.Name = name;
var isUnique = customerUniquenessChecker.IsUnique(this);
if (!isUnique)
{
throw new BusinessRuleValidationException("Customer with this email already exists.");
}
this.AddDomainEvent(new CustomerRegisteredEvent(this));
}
راهکار ارائه شده، برگرفته است از مطلب «تهیه XML امضاء شده جهت تولید مجوز استفاده از برنامه» با طراحی جدید به همراه آزمونهای واحد مرتبط
This was a very quick run down of some of the options available to you to prevent mass assignment. Which approach you take is up to you, though I would definitely suggest using one of the latter 2-model approaches. There are other options too, such as doing explicit binding via TryUpdateModelAsync<> but the options I've shown represent some of the most common approaches. Whatever you do, don't just blindly bind your view models if you have properties that should not be edited by a user, or you could be in for a nasty surprise.
And whatever you do, don't bind directly to your EntityFramework models. Pretty please.
In this post, I want to compare “DNTFrameworkCore” with “ABP Framework”.
ABP is one of most popular and well documented frameworks with high level abstraction that I learned a lot from it. It has many other features that I don’t list them in this post, because, DNTFrameworkCore has not them actually. Behind of ABP, there is a team. It has 123 contributors in GitHub. Also, all of features have related unit-tests.
In other side, DNTFrameworkCore is lightweight with low level abstraction. It is personal open-source project without any contributor and has unit-tests for small part.
I wrote this post to prove that thinking behind of DNTFrameworkCore completely different from ABP (at least in most sections)
