Activities of "hugol"

Hi,

First of all thank you very much your reply, it's much appreciated specially because I know that you are busy man :D

Just a quick reply, you mentioned:

In an ideal design, an application service should work like that to implement a use case of the application:

1. Get related entities from repositories
2. Use domain layer (domain services or entity methods) to manipulate them (perform business logic) - But do not implement business logic inside app service, just delegate the work to domain layer and orchestrate them.
3. Save changed entities via repositories (actually Unit Of Work pattern (EF DbContext)) already does it when you SaveChanges).

So, this simple method implement it:

public async Task Cancel(EntityRequestInput<Guid> input)
   {
       var @event = await _eventManager.GetAsync(input.Id);
       _eventManager.Cancel(@event);
   }

Gets entity from manager (could get it from repository - it would be better) and uses domain layer to perform the operation: It does not just set event.Cancelled = true; because maybe we want to force to perform additional business logic on event cancellation.

This is perfect, this is precisely what I was trying to say. When I was following the Examples and Step by Steps guides I got confused because they were not following the DDD principles (some parts were and some parts weren't). I know now that you used that approach to make the examples a little bit simpler.

Once more thanks for the reply. Cheers, H

Hello there,

I wasn't criticising, far from that. Your work is very appreciated and after working for 20 years in the software industry I know that there isn't such a thing as a perfect solution and that "theory" and "practice" don't always walk together :D

The reason is related to the fact that I was giving a deep reading to the documentation, checking the examples and I wasn't being able to have a clear view. On my mind I had questions like: (note: (you don't need to answer the next questions), they are here just to show you the type of questions that someone reading the documentation and seeing the examples may have.

• Why do I need a manager while using this framework since it creates a WebApi automatically from the Application Service?
• Should I keep everything in the manager, including the repository and make the ApplicationService just a "proxy"?
• Should I have a Repository and the Manager in the Application Service and if so which operations should I have. something similar to the example that you provided [https://www.codeproject.com/Articles/1043326/A-Multi-Tenant-SaaS-Application-With-ASP-NET-MVC-A#ArticleAppServices])

So perhaps I would ask you to answer just the last question. Why in your example you decided to have the repository and the manager at the application service? Why "Get" operations use the repository and the C,U,D operations are just a proxy to the manager? (again I'm not criticising, I'm just trying to brainstorm the decisions behind an architecture).

Keep up the good work ;) Cheers H

Hi,

Just a quick question following up a post that I did regarding the "Update Person" example in another thread. Following your recommendations I was able to implement the Update but I have a doubt after reading the recommended documentation: [https://aspnetboilerplate.com/Pages/Documents/Domain-Services]) [https://aspnetboilerplate.com/Pages/Documents/Repositories])

You have the following text on the Domain Services: Why Not Only Application Services? You can say that why application service does not implement the logic in the domain service? We can simply say that it's not application service task. Because it's not a use-case, instead, it's a business operation. We may use same 'assign a task to a user' domain logic in a different use-case. Say that we may have another screen to somehow update the task and this updating can include assigning the task to another person.So, we can use same domain logic there. Also, we may have 2 different UI (one mobile application and one web application) that shares same domain or we may have a web API for remote clients that includes a task assign operation.

Shouldn't we use always Domain Services and Managers instead of using repositories directly in the Application Services? Because even for simple CRUD operations, they will be most likely repeated for each, for example, different UIs.

Kind regards, Hugo

<cite>ismcagdas: </cite> Hi,

Actually we thought the pages in downloaded template contains update operations and it would be enough but maybe we are wrong.

We will consider adding update samples in step by step documents.

Thanks for sharing your problem with us.

Do you have any feedback on this subject? Would be nice to see an example implementing the Update for the main entity. New users that are using your framework to also learn some new skills struggle a bit with this part.

Thanks.

I will share my logic and how I will implement it.

Objectives and Restrictions:

• Seed All the Data in Development mode
• When the Host admin is creating a new tenant in PRODUCTION, the new tenant should have some pre populate management data.
• The Production DBs have to be update by a DBA. The process is: they review the scripts, backup the Prod DBs, Copy them to a Pre-PROD env, Specific Users Test the new version and then DBA will run the script against all PROD DBs (host and Tenants) Developers don't have access to the production DBs for security and data protection.

Consideration that I also used to make a decision (for now)

• When I'm in Debug mode my connection strings are aimed to my DEV environment.
• When deploying to the server I will do it in release mode.

Decisions

• I decided to use the DebugHelper
• I will generate a database script to give to the DBA using the "Update-Database –Script"
• The code:

if (Tenant == null)
            {
                // Host seed
                // Code removed from post for simplicity
            }
            else
            {
                InitialManagementDataBuilder(); // Countries, Post Codes, 

                if (DebugHelper.IsDebug)
                {
                    new CompaniesBuilder(context).Create();
                    new OtherEntity1Builder(context).Create();
                    new OtherEntity2Builder(context).Create();
                    ....
                }

Cheers and Thanks for the replying. HugoL

Ok. I will do some research and some tests later on. I will share here what I can find out.

Thanks for the reply. HugoL

Hello,

I couldn't find a thread related to this so I would like to ask what would be the best/correct way to only Seed some data when the Tenant is being created.

The scenario is something like this:

• The Host admin will create a new tenant for Client Z
• When creating a new Tenant you would like to pre-populate some data (let's say Countries, Currencies, Post Codes, etc.)

In the method:

protected override void Seed(EntityFramework.WebPropterDbContext context)

located in the Configuration.cs method we can add code on the following path:

else
            {
                //You can add seed for tenant databases using Tenant property...
            }

So repeating the initial question, what would be the best/correct way to only seed some data when the Tenant is being created in Production and to seed all the data in the development environment.

Something like:

// Run all default data
SeedTenantSetupData();
if (isDevelopmentEnvironment){
  SeedDevelopmentData();
}

Ok I added this to the Github.

Thank you, HugoL

The migration tool and the default host works well when using this connection string on the app.config and the web.config like this:
<add name="Default" connectionString="Data Source=tcp:s12.winhost.com;Initial Catalog=DB_######main;User ID=DB##_main_user;Password=***;Integrated Security=False;" providerName="System.Data.SqlClient"

The questions are:

• What parameters are supported in the connection string on the tenant page? or the connection is used as is?
• If I need to create the database first (which I did) can the Tenant creation page cope with that?

Thanks, Hugo

You welcome.

I understand your point of view. Perhaps just adding a recommendation something like "if you are using one database per tenant (Multi Database) you should use the Migration Tool to update all the databases.

Cheers, HugoL