Good morning.
I'm using domain events in my project, and the easiest way i found to implement it was by using MediatR.
But i don't want my project to directly depend on it, i want apply dependency inversion to hide the library.
Current code that has a dependency in Mediator, because of INotification interface
public class EmailConfirmedEvent : INotification
{
public Guid PassengerId { get; }
public string Email { get; }
public EmailConfirmedEvent(Guid passengerId, string email)
{
Email = email;
PassengerId = passengerId;
}
}
But i want to be like this:
public class EmailConfirmedEvent : IMyProjectDomainEvent
{
public Guid PassengerId { get; }
public string Email { get; }
public EmailConfirmedEvent(Guid passengerId, string email)
{
Email = email;
PassengerId = passengerId;
}
}
By some way i'll need to "convert" from mediator events/event handlers to my project events/event handlers.
What's the best way to do this.
Thanks in advance.
I ended up creating my domain event custom code using StructureMap and reflection to resolve the event handlers at runtime.
Code sample here: https://github.com/Henry-Keys/domain-events-sample
I generally make base classes that inherit from MediatR interfaces/base. Then if you change libraries (unlikely) you just have to update the base classes and the rest of the implement remains untouched.
Related
I'm working on a new project that uses CosmosDB and Entity Framework Core (via the Microsoft.EntityFrameworkCore.Cosmos NuGet package, version 5.0.7; the project itself is .NET Core 5). I'm new to both, and running into an issue I can't sort out.
In short, I need to save a complex object to the database. It's a big model that will have multiple collections of classes underneath it, each with their own properties and some with collections underneath them as well. I'm trying to configure EF with OwnsOne and OwnsMany to store these child objects underneath the top-level one. The code compiles, and will save to the database so long as all the owned objects are left empty. But whenever I put anything into an owned object, either with OwnsOne or OwnsMany, I get a pair of NullReferenceExceptions.
I've tried to strip my code down to the very basics. Here's how it currently looks.
Owner and owned classes:
public class Questionnaire
{
// Constructors
private Questionnaire() { }
public Questionnaire(Guid id)
{
Test = "Test property.";
TV = new TestQ();
Id = id;
}
public Guid Id { get; set; }
public string Test { get; set; }
public TestQ TV { get; set; }
// Public Methods
public void AddForm(Form f)
{
// not currently using this method
//Forms.Add(f);
}
}
public class TestQ
{
public TestQ()
{
TestValue = "test ownsone value";
}
public string TestValue { get; set; }
}
DbContext:
public class QuestionnaireDbContext : DbContext
{
public DbSet<Questionnaire> Questionnaires { get; set; }
public QuestionnaireDbContext(DbContextOptions<QuestionnaireDbContext> options) : base(options) { }
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.HasDefaultContainer(nameof(Questionnaires));
modelBuilder.Entity<Questionnaire>().HasKey(q => q.Id);
modelBuilder.Entity<Questionnaire>().OwnsOne(q => q.TV);
}
}
And the code from the service that calls the dbContext (note that this is based on a generic service that I didn't set up originally). The actual exceptions are thrown here.
public virtual TEntity Add(TEntity entity)
{
_context.Entry(entity).State = EntityState.Added;
_context.SaveChanges();
return entity;
}
Ultimately I need this to work with OwnsMany and a collection, but I figured it might be simpler to get it working with OwnsOne first. The key thing to note here is that if I comment out the line
TV = new TestQ();
in the Questionnaire class, the model persists correctly into CosmosDB. It's only when I actually instantiate an owned entity that I get the NullReferenceExceptions.
Any advice would be much appreciated! Thank you!
Well, I'm not sure why this is the case, but the issue turned out to be with how we were adding the document. Using this generic code:
public virtual async Task<TEntity> Add(TEntity entity)
{
_context.Entry(entity).State = EntityState.Added;
await _context.SaveChanges();
return entity;
}
was the issue. It works just fine if I use the actual QuestionnaireDbContext class like so:
context.Add(questionnaire);
await context.SaveChangesAsync();
I have a Web Api using Odata v3, with some entities a composite key, like this one:
public class AerodromoAdministracaoData
{
[Key]
[Column("idAerodromo", Order = 0)]
[DatabaseGenerated(DatabaseGeneratedOption.None)]
public short IdAerodromo { get; set; }
[Key]
[Column("data", Order = 1, TypeName = "date")]
public DateTime Data { get; set; }
public virtual Aerodromo Aerodromo { get; set; }
}
I followed this msdn article and created a NavigationRoutingConvention. The application handles composite keys fine now. However, navigation Links like this one don't work:
http://localhost/WebApiV3/AerodromoAdministracaoData%28idAerodromo=1,data=%272014-10-24%27%29/Aerodromo
I keep getting a "No HTTP resource was found that matches the request" as if the method was not implemented in the controller. By the way, this is the controller method:
[EnableQuery]
public Aerodromo GetAerodromo([FromODataUri] short idAerodromo, [FromODataUri] DateTime data)
{
AerodromoAdministracaoData result = Store.AerodromoAdministracaoData.Find(idAerodromo, data);
if (result == null)
{
throw new HttpResponseException(new System.Net.Http.HttpResponseMessage(System.Net.HttpStatusCode.NotFound));
}
return result.Aerodromo;
}
I found this question talking about exactly the same problem, but I haven't figured out how Nikon handled the issue.
Eduardo
From MSDN article Support Composite Key in ASP.NET Web API OData
public class CompositeKeyRoutingConvention : EntityRoutingConvention
{
....
}
The above routing convention can cover the following Uri templates:
~/entityset/key
~/entityset/key/cast
But, it can't cover ~/entityset/key/navigation
The fix is simple, just derived from NavigationRouteConvention as below
public class CompositeKeyRoutingConvention : NavigationRoutingConvention
{
...
}
Below is the debug information:
Please make sure: if you want support both Uris:
/AerodromoAdministracaoData%28idAerodromo=1,data=%272014-10-24%27%29
/AerodromoAdministracaoData%28idAerodromo=1,data=%272014-10-24%27%29/Aerodromo
You must have two custom routing conventions, one derived from EntityRoutingConvention, the other one derived from NavigationRoutingConvention.
Hope it can help. Thanks.
I have an asp.net website and I would like to organize it into three layers
DataAccess
Domain
UI
What specifically goes in each of these layers?
e.g
Data
- Models
- Repositories? Would that be just interfaces
- IoC?
Domain
- Services?
UI
- javascript
- Area specific models?
- css
Could someone provide a simple guideline for organizing an asp.net website like this?
As other people have said each situation is different, but for a basic architecture, I would probably go along with something like this. It has gotten me out of a few jams and up and running quite quickly.
Infrastructure Layer
This is where all the data access is done. Database connection management, etc.
The Repositories include all queries to the database.
The Dependency Resolution sits here too. Use your DI Container of choice.
Domain Layer
This is where all you business logic sits.
The Domain Services Interfaces are what the UI layer call to use your business logic
UI
Pretty obvious this one....
Code Example
--UI
public class MyController
{
private readonly IMySerivce _myService;
public MyController(IMySerivce myService)
{
_mySerivce = myService;
}
public void MyAction()
{
_myService.DoSomeAction();
}
}
--Domain
public Interface IMyService()
{
void DoSomeAction();
}
public class MySerivce : IMyService()
{
private readonly IMyRepository _myRespository;
public MySerivce(IMyRepository myRepository)
{
_myRepository = myRepository;
}
public void DoSomeAction()
{
_myRepository.Save();
}
}
public interface IMyRepository
{
void Save();
}
--DataLayer
public MyRepository : IMyRepository
{
public void Save()
{
//Manage Save here
}
}
Additionally I usually have a separate area for unit/integration tests.
Update
This most definitely is dependent on your situation. It is very hard to say what method is best without fully understanding what you are ultimately trying to build.
From the list below you can see which method works well for you or fits well with your architecture.
Regardless of which one you choose, your Repository Implementation will have to have a dependency on your Domain Objects project.
Some techniques in doing it include:
No Mapping
Your Domain Objects really then become dummy mappings to your tables. i.e. have a table in your database call User. Then have a Domain Object called User. This is by far the simplest technique.
--Domain
public class User
{
public int Id {get; set;}
public string UserName {get; set;}
public string FirstName {get; set;}
public string LastName {get; set;}
public string Password {get; set;}
}
--Infrastructure
public class UserRepository : IUserRepository
{
public Core.User GetById(int id)
{
return DBConnection.GetByIdQuery(id);
}
}
Mapping
Martin Fowler describes it here
It is possible in your infrastructure layer to have what are known as Domain Transfer Objects (DTO) that represent your database tables. Similar to above, a table called User, a DTO called User. Both having the same properties.
Your domain Entity then becomes a true representation of your domain and business logic.
The mapping of the DTO to your Domain Entity (search query) can be done in the Repository and the mapping of your Domain Entity to your DTO (save/update query) would also be done in your Repository.
To do your mapping you can either create custom mapping classes or use 3rd party tools like AutoMapper. I am a big fan of AutoMapper.
A sample code example would be along the lines of:
--Custom mapper
public class UserRepository : IUserRepository
{
private readonly IUserMapper _userMapper;
public UserRepository(IUserMapper userMapper)
{
_userMapper = userMapper;
}
public Domain.User GetUserById(int id)
{
var DtoUser = GetUserByIdQuery(int id);
return _userMapper.MapUserDTOToDomainEntity(DtoUser);
}
}
public class UserMapper : IUserMapper
{
public Domain.User MapUserDTOToDomainEntity(DataEntity.User dtoUser)
{
//Manual property mapping
}
}
--AutoMapper Example
public class UserRepository : IUserRepository
{
public Domain.User GetUserById(int id)
{
var DtoUser = GetUserByIdQuery(int id);
return Mapper.Map<Domain.User>(DtoUser);
}
}
Other examples include:
https://stackoverflow.com/questions/14724612
There are many many debates out there in blogs and here on SO about the value of DTO's,
including MSDN, this blog and these https://stackoverflow.com/questions/11237946, https://stackoverflow.com/questions/15148866
recently posted about questioning how unsafe static variables are, I've since discovered I need to get rid of them. But I cannot figure out how to? Was thinking a static Get() method for each class, that returns a single instance, but then that instance would have to be declared static.
So the only way to do it, is to have the instance references (for each helper, I.E user helper.cs, imagehelper.cs etc.) is to declare them as instance properties on some sort of globally accessible class? But which class? Is there something I'm missing here?
Code below of a sample class I need to change:
sing System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Mvc.Mailer;
namespace MVCWebsite.Helpers
{
public class AppSettings
{
public static void OnAppInit()
{
//General
AppName = "MyApp";
DesktopBaseURLs = new Dictionary<string, string>();
DesktopBaseURLs.Add("dev", "localhost:50560");
DesktopBaseURLs.Add("test", "www.test.whatever.com");
DesktopBaseURLs.Add("live", "www.whatever.com");
MobileBaseURLs = new Dictionary<string, string>();
MobileBaseURLs.Add("dev", "m.local.whatever.com");
MobileBaseURLs.Add("test", "m.test.whatever.com");
MobileBaseURLs.Add("live", "m.whatever.com");
//Emails
EmailHostName = AppName + ".com"; //For the moment atleast
NoReplyEmailAddress = "no-reply#" + EmailHostName.ToLower();
SupportEmailAddress = "support#" + EmailHostName.ToLower();
ErrorEmailAddress = "errors#" + EmailHostName.ToLower();
//Resources
TempFileURL = "/content/temp/";
UserDataURL = "/content/user-content/";
ProfilePicturesURL = UserDataURL + "profile-pictures/";
var a = GlobalHelper.GetURLAsServerPath(ProfilePicturesURL);
var b = a;
}
//General
public static string AppName { get; set; }
public static Dictionary<string, string> DesktopBaseURLs;
public static Dictionary<string, string> MobileBaseURLs;
//Emails
public static string EmailHostName { get; set; }
public static string NoReplyEmailAddress { get; set; }
public static string SupportEmailAddress { get; set; }
public static string ErrorEmailAddress { get; set; }
//Resources
public static string UserDataURL { get; set; }
public static string TempFileURL { get; set; }
public static string ProfilePicturesURL { get; set; }
//Methods
public static void SetAppURL()
{
}
}
}
I recommend creating an interface for your AppSettings class, so that you can use it in your controllers now, and implement it in different ways as you see fit:
public interface IAppSettings
{
string AppName { get; set; }
...
}
You can then implement it immediately with your static class via a wrapper class:
public class AppSettingsWrapper : IAppSettings
{
public AppName
{
get
{
return AppSettings.AppName;
}
set
{
AppSettings.AppName = value;
}
}
...
}
Later on, you can create an implementation of IAppSettings that uses session, or cookies, or database values, or whatever. The important thing is to abstract the way you store things so that you can implement in a way that meets your needs.
The answer to you previous question clearly stated that the IDictionary was the only unsafe variable in your static method because it's not thread safe. You just need to store these variables differently. You don't need to get rid of all of your static variables. You just need to change IDictionary to something thread safe.
By the way, someone there makes a good coment about web.config
Right I think I've figured it out, they should be stored as instance variables within Global.asax.cs. This file contains your Application class which inherits from System.Web.HttpApplication. This master class is limited to one instance (of itself) per request. So if you store any references to your helpers here, you can reference them by going, MvcApplication.MyHelper.DoSomething(); Someone please correct me if this is wrong, but seems right to me. "At any single point of time, an HTTPApplication instance handles only one request, so we don't need to think about locking and unlocking of any non static members, but for static members we do require. " -from : http://www.codeproject.com/Articles/87316/A-walkthrough-to-Application-State#c
Having almost no architectural experience I'm trying to design a DRY KISS solution for the .NET 4 platform taking an MVP approach that will eventually be implemented as a Desktop (WinForms) and Web (ASP.NET or Silverlight) product. I did some MVC, MVVM work in the past but for some reason I'm having difficulties trying to wrap my head around this particular one so in an effort to get a grip of the pattern I've decided to start with the simplest sample and to ask you guys for some help.
So assuming a quite simple Model as follows (in practice it'd most definitely be a WCF call):
internal class Person
{
internal string FirstName { get; set; }
internal string LastName { get; set; }
internal DateTime Born { get; set; }
}
public class People
{
private readonly List<Person> _people = new List<Person>();
public List<Person> People { get { return _people; } }
}
I was wondering:
What would be the most generic way to implement its corresponding View/Presenter triad (and helpers) for say, a Console and a Forms UI?
Which of them should be declared as interfaces and which as abstract classes?
Are commands always the recommended way of communication between layers?
And finally: by any chance is there a well-docummented, testeable, light framework to achieve just that?
I've written a number of apps that require a GUI and a winforms UI, the approach I have typically taken to implementing MVP is to create a generic view interface (you can subclass this for more specific views) and a controllerbase class which is given a view. You can then create different view implementations which inherit from the IView (or more specific view) interface
interface IView
{
event EventHandler Shown;
event EventHandler Closed;
void ShowView(IView parentView);
void CloseView();
}
class ControllerBase<T> where T: IView
{
private T _view;
public ControllerBase(T view)
{
_view = view;
}
public T View
{
get { return _view; }
}
public void ShowView(IView owner)
{
_view.ShowView(owner);
}
public void ShowView()
{
ShowView(null);
}
public void CloseView()
{
_view.CloseView();
}
}
Heres an example of how it would work in a specific case
interface IPersonView: IView
{
event EventHandler OnChangeName;
string Name { get; set; }
}
class PersonController: ControllerBase<IPersonView>
{
public PersonController(string name,IPersonView view) : base(view)
{
View.Name = name;
View.OnChangeName += HandlerFunction;
}
private void HandlerFunction(object sender, EventArgs e)
{
//logic to deal with changing name here
}
}
To implement this view in winforms, just make sure your form inherits from IPersonView and implements all the required properties/events and you're good to go. To instantiate the view/controller you'd do something like the following
PersonForm form = new PersonForm();
PersonController controller = new PersonController("jim",form);
controller.ShowView();