I need plan for build Notifications/Alerts system.
I have object named "Campaign" and it have "Status". Status can be Accepted, Rejected, Supplement, Work and others.
I want send Notifications/Alerts when the Status change.
E.q. e-mail notification and alert in my portal.
I don't want make it all in one controller where I operate on Campaign. So I was thinking about Delegates and Events. But in last I don't know enought to do it.
What I thinking about:
Domain model:
class Campaign {
CampaignStatus Status { get; set;}
}
abstract class Notification {
// properties
}
class EmailNotification {
// properties specific for email
}
class Alert {
// properties specific for alerts
}
class CampaignAlert {
// properties specific for campaign alerts
}
Services:
INotificationsService {
Send();
}
IAlertsService : INotificationsService {
Get(); // I need showing list of alerts too
GetAll();
Update(); // for updating info if alert was viewed.
Save(); // I need saving alerts in db.
}
And how I can do it with events? So much automatic as can. Ofcourse I can manualy call the AlertsService and make alert. But this is bad ;)
I was thinking about adding delegate and event to Campaign.
class Campaign {
public delegate void CampaignStatusChange(object sender, EventArgs e);
public event CampaignStatusChange OnCampaignStatusChange;
}
And connect event with:
class CampaignStatusChangeHandler {
public CampaignStatusChangeHandler(IRepository<bla bla> repository, INotificationsService notificationService) {
// these will be inject via ctor
}
//
}
I want made it as much as I can with SOLID, KISS, and DRY. Ofcourse with TDD and I using IoC to inject objects ;)
Summary I need notification service that I can indepentend send emails and alerts. I need display alerts on frontend.
My alert domain model like that:
public abstract class Notification
{
public string Title { get; set; }
public string Content { get; set; }
public DateTime Created { get; set; }
public NotificationType Type { get; set; }
}
public enum NotificationType
{
Email,
Alert
}
public class EmailNotification : Notification
{
public string From { get; set; }
public ICollection<string> To { get; set; }
public ICollection<string> Bcc { get; set; }
}
public class Alert : Notification
{
public object LinkedObject { get; set; }
public bool WasSeen { get; set; }
}
public class CampaignAlert : Alert
{
public CampaignAlertType CampaignAlertType { get; set; }
}
public enum CampaignAlertType
{
Accepted,
Rejected,
Active,
Finished
}
When I want to send Alert to user I want send email sometimes and alert.
Sometimes I want send only email and only alert.
I wouldn't use delegates and events here. Calling a method is much more transparent and you wouldn't have any benefits of using delegates and events.
My structure would look like that:
interface ICampaignService
{
// It's business logic
// 1. Updates campaign
// 2. Creates notification using builder
// 3. Uses notification sender to send notification
// (4. creates alert object for notification)
void UpdateCampaignStatus(int campaignId, Status status);
}
// Builds different notifications based on different
// campaign statuses. For instance assign different
// email templates and use different text.
interface INotificationBuilder<TNotification> where TNotification : Notification
{
TNotification Build();
}
interface INotificationSender
{
Send(Notification notification);
}
interface IAlertsRepository
{
Get();
GetAll();
Update();
Create();
}
Also possible (if there are different types of notifications)
// If you want to send different types of notifications like
// Email, Push, SMS etc. Each notification type requires different
// logic for sending notification. Strategy pattern is perfect here.
interface INotificationStrategy : INotificationSender
{
Send(Notification notification);
}
It's all depends on your application extensibility requirements. SOLID is very important, but make sure to avoid over-engineering (you mentioned KISS :)).
Related
I currently have a class with around 40 dependency injection. It is a hard to maintain and unit test. I am not sure a good way around.
The code is done for any type of application process that is needed to process (New License, License Renewal, Student Registration, ...), there are around 80 different types applications and what sections are associated with each application type is determined by a database table.
I have a class with all of the possible properties, there are a several more than listed but you should get the idea. Each the properties have their own set of properties that are basic data types or object pointing to other classes.
class Application
{
[JsonProperty(PropertyName = "accounting")]
public Accounting Accounting { get; set; }
[JsonProperty(PropertyName = "application")]
public Application Application { get; set; }
[JsonProperty(PropertyName = "applicationType")]
public ApplicationType ApplicationType { get; set; }
[JsonProperty(PropertyName = "document")]
public List<Attachment> Document { get; set; }
[JsonProperty(PropertyName = "employment")]
public List<Employment> Employment { get; set; }
[JsonProperty(PropertyName = "enrollment")]
public Enrollment Enrollment { get; set; }
[JsonProperty(PropertyName = "individualAddressContact")]
public IndividualAddressContact IndividualAddressContact { get; set; }
[JsonProperty(PropertyName = "instructors")]
public List<Instructor> Instructors { get; set; }
[JsonProperty(PropertyName = "license")]
public License License { get; set; }
[JsonProperty(PropertyName = "licenseRenewal")]
public LicenseRenewal LicenseRenewal { get; set; }
[JsonProperty(PropertyName = "MilitaryService")]
public List<MilitaryService> MilitaryService { get; set; }
[JsonProperty(PropertyName = "paymentDetail")]
public PaymentDetail PaymentDetail { get; set; }
[JsonProperty(PropertyName = "photo")]
public List<Attachment> Photo { get; set; }
[JsonProperty(PropertyName = "portal")]
public Portal Portal { get; set; }
[JsonProperty(PropertyName = "section")]
public List<Section> Section { get; set; }
[JsonProperty(PropertyName = "testingCalendar")]
public TestingCalendar TestingCalendar { get; set; }
[JsonProperty(PropertyName = "testingScore")]
public List<TestingScore> TestingScore { get; set; }
[JsonProperty(PropertyName = "USCitizen")]
public USCitizen USCitizen { get; set; }
}
So this class is sent/received to an Angular 10 front end using Web API's.
When an application is requested the sections and the different properties are initiated and if the application has be started the progress will be reloaded. So it is possible some of properties will be pulled from the database and sent to the Angular app.
So I have something such as
Load(applicationTypeId, applicationId)
{
Get the sections for the application type
For each section in the sections
switch sectionid
case Documents
Load all of the documents required for the application type and get any documents uploaded
case Accounting
Load the payment details, if no payment made calculate the payment
case IndividualAddressContact
Load the person name/address/contact and set a few defaults if the person hasn't started.
.....
next
}
Save()
{
Save the application
switch current section
case Documents
Save all of the documents for the application
case Accounting
Save the payment details for the application
case IndividualAddressContact
Save the person name/address/contact for the application
.....
get the next section
Update the application current section
}
I have put all of the items in the switch into their own classes but in the end I still have 1 point for serialization/deserialization and still end up with to many dependencies injected. Creating a unit test with over 40 dependencies seems hard to maintain and given I won't know which properties will/won't used until an application is requested and loaded from database. I am unsure how to get around the switch, without at some point and time having to have all of the dependencies injected into 1 class.
I would appreciate some ideas of how to get around this.
"I currently have a class with around 40 dependency injection..." - Oh my gosh!
"It is a hard to maintain and unit test..." - I don't doubt that in the least!
SUGGESTED REFACTORING:
Create a class that manages "Applications" (e.g. "ApplicationManager").
Create an abstract class "Application".
One advantage of "abstract class" over "interface" here that you can put "common code" in the abstract base class.
Create a concrete subclass for each "Application" : public class NewLicense : Application, public class LicenseRenewal : Application, etc. etc.
... AND ...
Use DI primarily for those "services" that each concrete class needs.
I'll bet the constructors for your individual concrete classes will only need to inject three or four services ... instead of 40. Who knows - maybe your base class won't need any DI at all.
This is actually a design we're actually using in one of our production systems. It's simple; it's robust; it's flexible. It's working well for us :)
I would recommend using convention over configuration principle, with the Service Locator.
Declare something like IApplicationHandler interface in your program, e.g.
public interface IApplicationQueryHandler
{
Application Populate(Application application);
}
public interface IApplicationSaveHandler
{
Bool Save(Application application);
}
Then, write pieces of your code, with dependencies and such, e.g.
public class AccountingApplicationQueryHandler : IApplicationQueryHandler
{
public Application Populate(Application application) {
//// Load the payment details, if no payment made calculate the payment
return application;
}
}
public class AccountingApplicationSaveHandler : IApplicationSaveHandler
{
public Bool Save(Application application) {
//// Save the payment details for the application
return true; // this just flags for validation
}
}
// repeat for all other properties
Then in your controller, do something like
public class ApplicationController: Controller
{
public readonly IServiceProvider _serviceProvider;
public ApplicationController(IServiceProvider sp) {
_serviceProvider = sp;
}
public Application Load(string applicationTypeId, string applicationId)
{
var application = new Application(); // or get from db or whatever
var queryHandlers = _serviceProvider.GetServices(typeof(IApplicationQueryHandler));
foreach(var handler in queryHandlers) {
application = handler.Populate(application);
}
return application;
}
[HttpPost]
public bool Save(Application application)
{
var result = true;
var saveHandlers = _serviceProvider.GetServices(typeof(IApplicationSaveHandler));
foreach(var handler in queryHandlers) {
result = handler. Save(application);
}
return result;
}
}
You would need to register your handlers, which you can do e.g. like so:
var queryHandlers = Assembly.GetAssembly(typeof(IApplicationQueryHandler)).GetExportedTypes()
.Where(x => x.GetInterfaces().Any(y => y == typeof(IApplicationQueryHandler)));
foreach(queryHandler in queryHandlers) {
services.AddTransient(typeof(IApplicationQueryHandler), queryHandler);
}
// repeat the same for IApplicationSaveHandler
Now finally, you can write unit tests for part of the code like so
[TestClass]
public class AccountingApplicationQueryHandlerTests
{
[TestMethod]
public void TestPopulate()
{
// arrange
var application = new Application();
var handler = new AccountingApplicationQueryHandler(); // inject mocks here
// act
var result = handler.Populate(application);
// Assert
Assert.AreEqual(result. PaymentDetail, "whatever");
}
}
And you can test that your controller calls the right things by mocking IServiceProvider and injecting that with a couple of dummy handlers to confirm they are called correctly.
Following zaitsman's answer you also could create AggregatedApplicationQueryHandler and AggregatedApplicationSaveHandler and pass collection of concrete implementation of IApplicationQueryHandler and IApplicationSaveHandler to its constructor.
Then you don't need foreach loop inside controller(you loop over handlers inside aggregated handler) and always have only one handler passed to controller. Passing its by constructor parameter shouldn't be so much painful.
You also could create facade over some small services and aggregate theirs functions into one bigger facade service.
Hi I'm looking to create a simple webhook receiver and dump the data into a table.
This is for receiving SMS using Zipwhip. Zipwhip will send a post with JSON.
Need to receive the JSON and process.
What is a simple way to accomplish this.
Thanks in advance.
In ServiceStack your callback would just need to match the shape of your Response DTO, e.g:
[Route("/path/to/callback")]
public class CorpNotes
{
public int Departments { get; set; }
public string Note { get; set; }
public DateTime WeekEnding { get; set; }
}
// Example of OrmLite POCO Data Model
public class MyTable {}
public class MyServices : Service
{
public object Any(CorpNotes request)
{
//...
Db.Insert(request.ConvertTo<MyTable>());
}
}
Example uses Auto Mapping Utils to populate your OrmLite POCO datamodel, you may want to do additional processing before saving the data model.
If the callback can send arbitrary JSON Responses in the payload you can use an object property to accept arbitrary JSON however we'd recommend using Typed DTOs wherever possible.
This can be what the receiving method in your controller can look like on the receiving side. Make sure that your receiving and sending json object match.
[HttpPost]
[Route("Edit")]
public JsonResult Edit([FromBody] CorpNotes newMessage)
{return Json(TotalWeekNoteSearch);}
public class CorpNotes
{
public int Departments { get; set; }
public string Note { get; set; }
public DateTime WeekEnding { get; set; }
}
I am actually working on a .net project receiving Json from a Angular front end, so this should be the same concept. Also make sure that what you are receiving is truly a workable object such as.
{Departments: 4, Note: "This is notes 2020Q1W13", WeekEnding: "2020-01-25T00:00:00"}
Also try looking into this example which would be helpful in regards to webhooks.
public class MyWebHookHandler : WebHookHandler
{
public MyWebHookHandler()
{
this.Receiver = "custom";
}
public override Task ExecuteAsync(string generator, WebHookHandlerContext context)
{
CustomNotifications notifications = context.GetDataOrDefault<CustomNotifications>();
foreach (var notification in notifications.Notifications)
{
...
}
return Task.FromResult(true);
}
}
The type of the data is typically JSON or HTML form data, but it is possible to cast to a more specific type if desired.
I am trying to create Payment Gateway abstraction, for one of my projects using Asp.Net Core, so that clients can integrate their payment gateways, by creating derived libraries. My application will load the derived libraries and call the methods.
Below is an interface that all payment gateways must implement. This lies in the Core library, let's call it PaymentGateway.Core.dll. This library is part of the main application.
namespace PaymentGateway.Core
{
public interface IPaymentGateway
{
string Name { get; }
// The purpose of this function is to transform the order details into an object,
// as expected by the underlying gateway's apis
object CreatePaymentRequest(Order request);
// The purpose of this function is to transform the payment response object,
// received from the payment gateway api,
// into an application entity that represents this payment.
Payment ProcessPaymentResponse(object response);
}
// Order for which the payment to be collected. This entity is stored in DB
public class Order
{
string UserId { get; set; }
string ProductId { get; set; }
double OrderTotal { get; set; }
}
// A payment attempted for an Order. This entity is stored in DB
public class Payment
{
Order Order { get; set; }
string PaymentGateway { get; set; }
double Amount { get; set; }
PaymentStatus Status { get; set; } // Failed, User Aborted, Success
}
}
Below is an example of PayPal integration library, let's call it PaymentGateway.PayPal.dll. This library references the core library and implements the PaymentGateway interface.
namespace PaymentGateway.PayPal
{
class PayPal : IPaymentGateway
{
public string Name { get => "PayPal"; }
public object CreatePaymentRequest(Order request)
{
:
:
}
public Payment ProcessPaymentResponse(object response)
{
:
:
}
}
}
The process flow in the core library to execute a payment would be like :
The buyer clicks on the PayPal button on the webpage.
The core application then initializes the PayPal object.
The core application then calls the CreatePaymentrequest() function with the order details. The function will transform the order details into PayPal Payment Request format.
The returned data is passed to PayPal apis to initiate a transaction.
After PayPal api finishes, it returns the response in a its defined format.
The response from PayPal api is passed to the server, which calls ProcessPaymentResponse() on the PayPal object. This function transform the response into Payment object.
The problem i have is that the application ( Core ) doesn't understand the return type of CreatePaymentRequest(), as it is depends on the called gateway. Similarly, for ProcessPaymentResponse() the argument type is gateway specific and the type will be defined in the gateway library.
For now i am forced to use System.Object. Is there any better solution to the problem ?
public interface IPaymentGateway<T> where T : class
{
string Name { get; }
T CreatePaymentRequest(PaymentRequest request);
PaymentResponse ProcessPaymentResponse(T response);
}
public class PayPal<T> : IPaymentGateway<T> where T : class
{
public string Name { get; }
public T CreatePaymentRequest(PaymentRequest request)
{
throw new NotImplementedException();
}
public PaymentResponse ProcessPaymentResponse(T response)
{
throw new NotImplementedException();
}
}
public class Example
{
public void ExampleMethod()
{
IPaymentGateway<Foo> paypal = new PayPal<Foo>();
var name = paypal.Name;
Foo paymentRequest = paypal.CreatePaymentRequest(new PaymentRequest());
var paymentResponse = paypal.ProcessPaymentResponse(new Foo());
}
}
public class Foo
{
}
public class PaymentResponse
{
}
public class PaymentRequest
{
}
Instead of returning an object why not make it generic and have them pass in the type?
(using the Microsoft.AspNet.Identity)
The IdentityMessage message within the EmailService has 3 properties
public virtual string Body { get; set; }
public virtual string Destination { get; set; }
public virtual string Subject { get; set; }
When you only have 1 "from" adress it is enough, but if you want more then one "from" address, it is a problem and I need the extra property.
public string From { get; set; }
So I extended the class IdentityMessage (like I dit with Users and roles)
public class ExtendedMessage : IdentityMessage
{
public string From { get; set; }
}
So I changed the default implementation
public class EmailService : IIdentityMessageService
{
public async Task SendAsync(IdentityMessage message)
{
await configSMTPasync(message);
}
// send email via smtp service
private async Task configSMTPasync(IdentityMessage message)
{
// SEND MAIL
}
}
With
public class EmailService : IIdentityMessageService
{
public async Task SendAsync(ExtendedMessage message)
{
await configSMTPasync(message);
}
// send email via smtp service
private async Task configSMTPasync(ExtendedMessage message)
{
// SEND MAIL
}
}
But IIdentityMessageService is still refering to the original IdentityMessage (it is not working as espected)
What is the best way to get this working (using Microsoft.AspNet.Identity; framework)?
Thanks in advance.
You cannot use inheritance because once entity is loaded from the data source EF will not know about inheritance and because of that it will instantiate base type without your properties instead of derived type with your properties. Any inheritance must be mapped in EDMX if EF have to work with it.
Using partial class will solve your problem but:
All parts of partial class must be defined in the same assembly
Properties from your partial part are not persisted to the database
Properties from your partial part cannot be used in linq-to-entities queries
I have a WCf service with Contracts shown below.
[MessageContract]
public class ServiceRequest
{
[MessageBodyMember]
public int RequestId { get; set; }
[MessageBodyMember]
public OrderDetails OrderDetails { get; set; }
}
[DataContract]
public class OrderDetails
{
[IsLogRequired]
public int OrderId { get; set; }
[IsLogRequired]
public int Quantity { get; set; }
public string CustomerName { get; set; }
}
[IsLogRequired] is custom Attribute.
We need to get all properties in the request which have "[IsLogRequired]" attribute when the request is received. We want to do it as generic solution so that it can be plugged into all services.
We thought of using "MessageInspector" to do this implementing "IDispatchMessageInspector".
How do i get the actual request object from "System.ServiceModel.Channels.Message" parameter of IDispatchMessageInspector.AfterReceiveRequest() method?
Please correct me if i am using a wrong interface or wrong method. Any other solution to this?
I am assuming that "[IsLogRequired] is custom property." means a custom attribute...
Simple answer is that there is no solution to transfer custom attributes that are decorating the data contract as you described it.
Data contracts should be pure and not encumbered by business logic. The know how about the what should be done with various fields belongs to a service implementation.
Possible approach could look like this:
public class OrderService : IOrderService
{
private void ProcessOrder(Order order)
{
var ra = new AuditMetadataResourceAccess();
MethodInfo[] fieldsToLog = ra.GetLoggingFields(typeof(OrderDetal));
if (fieldsToLog.Any())
{
var logger = new LogingEngine();
logger.Log(fieldsToLog, order.OrderDetails);
}
}
}
You could move this implementation inside message inspector or operation invoker. Carlos Figueira has extensive description of each WCF extensibility point.
"How do i get the actual request object from "System.ServiceModel.Channels.Message" parameter of IDispatchMessageInspector.AfterReceiveRequest() method?"
I am assuming you are referring to Web request. WebOperationContext.Current but you need to have ASP.NET Compatibility Mode turned on.