Base solution for your next web application

Activities of "eggersa"

The impersonation feature works fine when runnig the application (version 0.8.4) on my local machine from Visual Studio. However, as soon as I run the application on IIS 8, the impersonation does not work anymore. The reason is that the built in cache manager (not using redis) seems to have some sort of a problem.

Within the AccountController (as is from the aspnetzero template) the impersonation token is put in the cache to be retrieved by the next action method (ImpersonateSignIn). However, at this point, the cache is empty when running on IIS 8.

public virtual async Task<JsonResult> Impersonate(ImpersonateModel model)
{
	// ...
	var result = await SaveImpersonationTokenAndGetTargetUrl(model.TenantId, model.UserId, false);
	AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);
	return result;
}

[UnitOfWork]
public virtual async Task<ActionResult> ImpersonateSignIn(string tokenId)
{
	var cacheItem = await _cacheManager.GetImpersonationCache().GetOrDefaultAsync(tokenId);
	if (cacheItem == null)
	{
		// gets thrown on IIS 8 but not on localhost
		throw new UserFriendlyException(L("ImpersonationTokenErrorMessage"));
	}
	// ...
}

Thank you for your help =).

Thank you for the answers. I prefer the way with the event bus since it seems business related and I think we both agree that business rules have no "business" in the orm layer. However, inside the HandleEvent method it seems difficult to get the original object:

public class ShootingStatisticsHandler : IEventHandler<EntityUpdatingEventData<Shooting>>, ITransientDependency
    {
        private readonly IRepository<Shooting> shootingRepository;

        public ShootingStatisticsHandler(IRepository<Shooting> shootingRepository)
        {
            this.shootingRepository = shootingRepository;
        }

        public async void HandleEvent(EntityUpdatingEventData<Shooting> eventData)
        {
            Shooting original = await shootingRepository.FirstOrDefaultAsync(eventData.Entity.Id);
            // ...
        }
    }

And the update method in the application layer looks like this:

public async Task UpdateShooting(ShootingEditDto input)
        {
            var shooting = await shootingRepository.FirstOrDefaultAsync(input.Id.Value);
            input.MapTo(shooting);
        }

For some reason, the repository in the event handler returns the already changed object. Is there some caching going on behind I am not aware about?

To allow for statistics on an entity class I need to somehow log changes with the current date of a small set of properties for that specific entity. However, since there are dozens of ways to do this (technically) I was wondering on how to properly do this?

  • The simplest way I could think of would be to have a collection with the logs inside the entity class and simply add a new log entry inside the setter of the property that needs to be logged. But this seems messy in many ways.
  • Another idea is to create a custom repository (by inheriting the generic repository) and log changes of the properties in the insert or update methods respectively. But that adds logic to the repository which is out of its responsibility.
  • Further ideas involve the event bus or a custom interceptor. Maybe the interceptor is the way to go?

I noticed that some of the application "logic" is inside mvc controllers like the ProfileController or FileController. I was now wondering why? My guess is, that those APIs are consumed by 3rd party javascript libraries and therefore must not wrap their results in DTOs.

To allow for spatial search with MS SQL, Entity Framework provides the namespace System.Data.Entity.Spatial that includes the type DbGeography. This property enables me to easily do spatial searches with Entity Framework like so:

var university = (from u in context.Universities 
                        orderby u.Location.Distance(myLocation) 
                        select u).FirstOrDefault();

However, this feature is heavily database related and depends on the Entity Framework which in turn would mean that the Domain Model depends on the OR-Mapper which is kinda ugly. Is there a recommended approach to somehow use this feature without my Domain Model being dependent on the actual OR-Mapper?

Unfortunately, the documentation for the DTOs does not say much about the IOutputDto interface. Only that the interface should be implemented by "output DTOs". So, whats the technical reason to implement that interface?

Hello ismcagdas

Thank you for your answer.

Since I am not using the Layout 4, but Layout 3 I cannot describe the steps. However, with your answer I will be able to investigate the problem myself ;).

Within the app.js are the route configurations like this:

$stateProvider.state('tenant.settings', {
                url: '/settings',
                templateUrl: '~/App/tenant/views/settings/index.cshtml',
                menu: 'Administration.Settings.Tenant'
            });

There is this "menu" property which does not seem to be an official property at all. See $stateProvider API. From the ASP.NET Zero Getting Started tutorial, all I know is that this property has something to do with the highlighting of the currently active menu in the navbar. Since in my case this highlighting mechanism is somewhat buggy I would like to know where this menu property gets processed / handled to further investigate my issues.

Found it myself:

Create a new folder in the <MyProjectName>.Core Project e.g. GeoMapService and then create the appropriate IGeoMapService interface within that folder and a concrete implementation BingGeoMapService.

For my application project, I need to consume some of the services that are provided by the Bing Map API (web services). So far, I wasn't able to find the right place in the ASP.NET Zero Solution to put those service calls in a way, that is unit test compatible. Also, those bing map services are not meant to be directly invoked by the presentation layer.

First I though of the application service layer. But that seems wrong since the application service layer is meant to be directly accessed by the presentation layer.

Then I checked the domain service layer which is only accessible by the application service layer, but not by the presentation layer. But to me, the domain service layer seems more, like its name already suggests, domain related whereas the bing map is not within the domain.

Now I am looking for an answer where one would put this bing map api calls within the ASP.NET Zero solution? The class that wraps those calls should be unit testable and registered to the dependency injection system.

Showing 21 to 30 of 35 entries