Using EventAggregator with Unity and PRISM, is there a way to get the list of subscribers to a specific event?
I know that some people will say that "Why do you want to know this, the whole point of using an EventAggregator is so that we don't care who or how many subscribers".
This is purely an exercise that I want to carry out it is not for any specific purpose.
EventAggregator must store a list of subscribers is there a way to expose this list?
Yes, the subscriber information is contained within the EventAggregator object graph. Unfortunately (for your request), this information is stored within private fields.
Events are stored in a private Dictionary<Type, EventBase> events. The subscriptions are stored within the event itself (in EventBase) as a
private readonly List<IEventSubscription> _subscriptions = new List<IEventSubscription>();
One option to retrieve the subscription information is to use reflection to access the private member variables (assuming reflection permission exists).
If you can modify the events then another option is to expose this information via the specific PubSub<EventBase> since EventBase allows access to subscriptions for subclasses via the protected ICollection<IEventSubscription> Subscriptions property. For example:
public class MyEvent : PubSubEvent<MyEventData>
{
public new ICollection<IEventSubscription> Subscriptions => base.Subscriptions;
}
Then you can query the event:
var myEvent = eventAggregator.GetEvent<MyEvent>();
var sub = (EventSubscription<MyEventData>) myEvent.Subscriptions.FirstOrDefault();
MethodInfo method = sub.Action.Method;
object target = sub.Action.Target;
If you don't need the specific EventSubscription<T> data (e.g. just want to know subscription counts) then you could avoid the specific cast and use the IEventSubscription interface.
Related
I have an asp.net core 3.1 based project. I need to add a custom validation rule that will require a database call in ordered to determine the validity of the value.
For example, when creating a new user, I need to validate that there is no other username in the database with the same username before allowing the user to be created.
If I can create a custom attribute UniqueUsername, then I should be able to do something like this
public class UniqueUsername : ValidationAttribute
{
private readonly UserManager _manager = manager;
public UniqueUsername (UserManager manager)
{
_manager = manager;
}
protected override ValidationResult IsValid(object value, ValidationContext validationContext)
{
string username = value.ToString();
if(_manager.Exists(username))
{
return new ValidationResult("The username provided belong to a different user.");
}
return ValidationResult.Success;
}
}
But, _manager.Exists(username) is a synchronous call. I want to avoid blocking the main thread, so I want a way to call await _manager.ExistsAsync(username) instead to avoid blocking the main thread.
Is there a way to create an attribute that would validate a single property and write errors "if any" to the ModelState?
If this isn't possible using data-annotation, is there an different way to validate property while writting errors to ModelState so when ModelState.IsValid() or TryValidateModel(model) are called, the attribute is called?
The data-annotations you add in your model are meant to validate the data present within the model (although some can also be translated into your database). These are meant to be reused even if you were to use your models on a client framework.
You can use the ModelState functions you mentioned to make async calls to your database. If you want to remove the logic from your controller, you can create utility functions to do so.
If you are open to third-party libraries, there is a great and popular validations library called Fluent Validation. Here is a documentation on how you can make async calls with it: https://docs.fluentvalidation.net/en/latest/async.html
I encountered a Problem with the DI framework of netcore. I am aware about the different ways to register an type in the DI container.
Specifically I am interested in the .AddSingleton method. There are many overlaods of this method.
My Problem is that I want to ensure that when I register the same class in different ways (with an interface and just with the class type), then two instances are created, one for each "registration" way.
Lets say I have an Interface called ISomeInterface an one implementation of it named ImplementationOfSomeInterface.
In my case I want the DI system to create an instance whenever the ImplementationOfSomeInterface is requested. Further I have some places where I define the dependency just with the interface ISomeInterface.
The Problem is that the DI system returns 2 instances of ImplementationOfSomeInterface. One for the case where the dependency is related of the class and one for the case where the dependency is given by the Interface.
I already checked many documentation and tutorials, but they all just explain the differences of AddSingleton, AddScoped etc...
// registration with the class type
services.AddSingleton<ImplementationOfSomeInterface>()
//registration with an interface and the corresponding 'same' class type
services.AddSingleton<ISomeInterface, ImplementationOfSomeInterface>();
//--------- now the usage of it -------------------
public TestClassA(SomeInterfaceImplementation instance)
{
var resultingInstA = instance;
}
public TestClassB(ISomeInterface instance)
{
var resultingInstB = instance;
}
//I would expect that resultingInstA is pointing to the very same object of
//resultingInstB => but they are different!
I would expect that resultingInstA is pointing to the very same object of resultingInstB => but they are different!
How can I achieve that I get the same instance back?
You can do it by registering an instance of the class rather than just the type.
var instance = new ImplementationOfSomeInterface();
services.AddSingleton(instance);
services.AddSingleton<ISomeInterface>(instance);
Now any attempt to resolve ImplementationOfSomeInterface or ISomeInterface will both return the instance initialized here.
I have 2 different user account type and they both are stored in their respective tables (Members in Member table and Admin in Administrator table). Now i want to create a common function to access user info for any type of user, so i was looking a for generic function but i am stuck with returning respective class, I have create 2 class MemberInfo for normal users and AdminInfo for Admin usersNow if the generic class passed to this function is MemberInfo than it should process normal user details and return MemberInfo class, and if it's admin users, then it should return AdminInfo class.
Here is something what i have tried but unable to achieve my goal.
Public Function GetAllMembers(Of T)(ByVal accountType As AccountType) As List(Of T)
Dim T_ReturnValue As List(Of T)
Dim returnType As Type = GetType(T)
If returnType Is GetType(MemberInfo) Then
Dim _list As New List(Of MemberInfo)
With New OleDbDataAdapter("SELECT ACCOUNT_NO, COUNTRY FROM Member", Globals.DatabaseConnection)
Dim dt As New DataTable
.Fill(dt)
For Each row As DataRow In dt.Rows
Dim memberInfo As New MemberInfo
memberInfo.AccountNo = row("Account_No").ToString
memberInfo.Country = row("Country").ToString
_list.Add(memberInfo)
Next
End With
Return DirectCast(_list, List(Of T))
End If
End Function
Can anyone help me how i can return respective class, for now i wanted to return memberinfo class only.
Two ways:
You can have two overloaded functions that return different classes.
You can declare the function as Object, and return either class.
You can follow these steps.
Create an abstract class say "User" . And then Member and Admin has to extend that base class user. Assuming, both has same set of properties and that is why you have started using T to make it generic. But as you have said both has different DB table store.
If you different methods defined for Member and Admin, you can segregate them by using interface. Say Member can Send Friend request, so you can have an interface ( Say ISendRequest), that will have Send method definition only. And if Admin can Add new member ,then you can have interface say IAddMember, and Admin will implement IAddMember , Member will implement, ISendRequest.
KEY point Now, define an interface say IGetAllUser with method GetAllUser and User class has to implement that, but it will have abstract method GetAllUser. So point here is you have to have to write this one GetAllMembers, instead each derived class will have method to get corresponding List .
Sample code snippet. This can even accommodate the scenario if both Member and Admin has different properties.
But if you have same properties, then you can define a function in Base class, that takes Datatable and just sets required properties, as both member and admin has same properties. So the sole purpose of GetAllUsers implemented in Member and Admin class is to pass required table name to Data Access layer and get DataTable and pass that to function defined in base class to set required properties and build List of User.
public interface IGetAllUsers
{
List<User> GetAllUsers();
}
abstract class User : IGetAllUsers
{
public abstract List<User> GetAllUsers();
}
class Member : User
{
public override List<Member> GetAllUsers()
{
// Assuming there is data access layer, to get details
}
}
class Admin : User
{
public override List<Admin> GetAllUsers()
{
// Get all admin
}
}
Right. Before addressing your specific question, I want to start at the lower level.
In theory, an admin is a user, so at database level this should rather be implemented so that there is a [Users] table that stores all kinds of users including admins. Then you should add another table called [Admins] which links to the [Users] table through an FK and stores all additional fields that relate to admins only. This is called ISA / inheritance relation in RDBMS theory.
At application level, this will translate to two business classes, one for [User] and one for [Admin], where [Admin] will inherit from [User] class. You can then write a function that returns a [User] object. Since [Admin] inherits from [User], polymorphism will allow you to return [Admin] object from the same function. Then your caller can confirm the returned object type either through type checking, or you can store a boolean field in [Users] table called IsAdmin that will be true for administrators.
I want to pass a object to workflow as input parameter, without creating instance of it, as this object is already filled up with lot of sub-objects, and I want to run lot of rules on that object. I want to use
WorkflowInvoker.Invoker(this); Is this possible in Windows Workflow Foundation 4.0, If so, what should I keep in InArguments as the type?
Thanks In Advance,
Thanks for your input....
Sorry, I think I haven't kept the question correctly, I had a business class used by bank customers, class is like this,
public partial class BankName.DTOS.clsCardDetails : BaseClass
{
public string _mBankStatusCode;
protected override string IsCreditCard(HttpContext ctx)
{
Status = ctx.Request.Form["Trans_Status"];
_mBankStatusCode = Status.ToString();
}
}
Now, I have to pass this class object to workflow foundation, I should not create new instance of this class in workflow again. Because in workflow, I want to get the status, so ideally what I thought of passing to workflow is object of "BankName.DTOS.clsCardDetails". That is my question.
InArguments<> to workflow is object of BankName.DTOS.clsCardDetails
Arguments passed into a workflow need to be put into a dictionary and the dictionary is passed into the workflow.
var dictionary = new Dictionary<string, object> { { "BankName", _bankNameObject } };
WorkflowInvoker.Invoke(this, dictionary);
The key must have the same name as your InArgument and your object must have the same type as your InArgument.
You can pass as many arguments as you like into the workflow via the dictionary.
See http://blogs.msdn.com/b/rjacobs/archive/2011/05/26/passing-arguments-to-workflow-activities-again.aspx
I have created a custom MembershipProvider in an MVC web appliocation. My GetUser function returns an instance of my own custom Employee class which inherits from the standard MembershipUser. This allows me to supply additional details for the each user such as various employee details.
public override MembershipUser GetUser(string username, bool userIsOnline)
{
return new ModelRepository().GetModels<Employee>().Where(e => e.UserName == username).FirstOrDefault();
}
The problem I'm having, the membership provider spawns a new instance of my repository class (which creates a new DbContext) to retrieve the Employee object. This Employee object is then passed to whatever request/controller action called the Membership api.
Employee currentUser = (Employee)Membership.GetUser();
That calling request will often want to create a new object in memory, lets say a new SicknessRecord and assign the user retrieved earlier to that record and then save it to the DB with its own model repository. You can probably see where this is going, the framework complains that I'm trying to save an object (the user) with a context that it wasn't initially retrieved with.
My current, rather hackish solution is to just use the ID of the user retrieved from the Membership.GetUser and go and re-retrieve the Employee object from my current model repository.
newSickness.Employee = this.modelRepository.GetModelById<Employee>(this.me.Id.Value);
I've tried detaching the Employee object but then it loses its lazy loaded properties and I have to remember to try and attach it again to my current repository/context.
I've also read it is good to have your custom membership provider share the same context that the current request would be using. Any ideas how to achieve this, how do I ensure the membership provider uses the same context as the one spawned when a user executes a controller action?
You can have one separate DbContext instance for each controller.
public class SomeController : Controller
{
private DbContext context = new DbContext();
private CustomMembershipProvider membershipProvider = new CutomMembershipProvider(this.context);
... Actions ....
}
As far as I know, one context per controller is good practice.
By the way, if you have several repositories try to use UnitOfWork with Repository pattern.