Hot answers tagged

8

This is an event handler, in addition to being a method. The convention for naming event handlers is EventOrigin_EventName(...). Event origin can be a name of an instance (camel case), or a name of a class (Pascal case), or some other meaningful name (Pascal case). Event name is Pascal case. Underscore between. Visual Studio uses this naming convention ...


5

I highly recommend you view Jimmy Bogard's NDC presentation on his approach to modelling http requests https://www.youtube.com/watch?v=SUiWfhAhgQw You will then get a clear idea of what Mediatr is used for. Jimmy does not have a blind adherence to patterns and abstractions. He's very pragmatic. Mediatr does clean up controller actions. As for the exception ...


4

The entry point of the application (the UI project) must setup the DI container, providing implementations of all the dependencies. That's why it must have direct connection (reference) to all the other projects. What is important is that the UI classes have dependencies only on BLL classes. The additional references are only for setting up DI.


3

The fact that tasks and users are stored in database tables is an implementation detail. You don't really want the tables to reference each other or to replicate databases, you just need a logical association between a task and a user. Each of the three systems you described can be implemented as its own web service, with relations crossing service ...


3

public decimal? TotalPercentage { get { return _percentage = (TheoryTotal + PracticalTotal) / (TheoryFullMarksTotal + PracticalFullMarksTotal); } set { _percentage = value; } } The behavior of this property is kind of overdefined, and it needs more thought. If the client code assigns the new value, and immediately reads the TotalPercentage back, ...


2

First point - For simplicity, the answer by Rumen is correct. What I do in larger solutions is to have a separate Infrastructure project which set's up the dependency injection container (in .net core, this would be the IServiceCollection). For example in my current solution I have both a Website & an API. Both of these call methods in my ...


2

The Model-View-Controller pattern is a UI pattern that follows a few basic principles: The View is a User Interface, a thin veneer in front of the Controller. The only logic that should be in the View (i.e. "Code-Behind") is that logic which pertains directly to interacting with the user. The Controller is a thin veneer in front of the Model. It acts as a ...


2

My experience with xamarin is that its a bit of a jack of all trades. If you are keen to keep with a single tech stack then yes, .net core/framework apis + xamarin + azure is great. You can quickly get an app out on iPhone, Android and Windows But, if you want a very polished app, which uses the UI specific to each platform to ita best advantages you may ...


2

What you are describing is a single-tenant application. What you want is a multi-tenant application. The difference being that a single-tenant app is one codebase that is copied and rolled out for one customer at a time. Whereas, a multi-tenant app is one codebase that is deployed to one location and multiple customers access it, often via different ...


2

A role is set of functionality grouped as one like in your case SALESMAN what a salesman can do is driven by permissions, so permission define what functionality is allowed or not. Basically now there is user which is performing SALESMAN role for which user gets certain functionalities based on permissions which it can perform. Now when a user with SALESMAN ...


2

Your question is very broad, so expect only to get a broad answer. The general strategy for solving these kinds of problems is to make the requirements customizable. This can be done by introducing run time or compile time switches, configuration files, special code which is only used for a specific customer, "plugins", and so on. From what you wrote, in ...


2

You may use Controller for rendering the views. In AP.NET MVC, it basically works similar to that of WEB-API, but it's derived from APIController class instead of Controller class. As the name states Web API, controllers meant to handle the serialised requests. You can also create a Web API project using the "Web API" template. The Web API template uses ASP....


1

This is just my opinion, but I feel like I disagree with Ewan in some ways. I think it depends. I think I definitely wouldn't be returning the EF objects to your client. I would use a package like AutoMapper or whatever to map them to DTO objects that is used only for transporting data to and from client. However, I don't think it's necessarily bad ...


1

Best practice is to hide the EF stuff. This allows you to share you models without forcing the EF dependency, maintain a separate data layer, run unit tests etc etc You can do this by mapping the EF generated to your models, or by using code first models if you don't end up having to add attributes to them. I would add an extra Project.Repository to ...


1

Its generally better to provide fine grained permissions, this makes it possible to change the exact set of information and actions available to a given user. But as you've noted this means being uber specific. One solution is to order your permission names hierarchically, and use a matching technique like prefix matches, or full regexs. ie: Customer....


1

Presumably you're talking about ASP.NET Core. Because the last major release of ASP.NET MVC is over 8 years old. I hope you're not replacing a dead technology with one that is on life support. What you need to keep in mind is that monster has a decade of decisions, behaviours and subtle side effects that could be a nightmare to replicate in a new code base. ...


1

At the end of the day, you are doing a rewrite of your application. Whether it's little by little, or all at once, the application you end up with is completely different from what you received. There are no automated ways to make the changes you want. Once you come to grips with that fact, you have to decide what you want to maintain in the future. ...


1

There is no automated migration path from Webforms to MVC. You will find several articles on the internet about how people have done it manually, but each involves rewriting the code, so the process that worked for them may not fit your code. Personally I would advise either not doing it at all (Refactoring rarely pays off). Or writing a "version 2" from ...


1

The correct way to do this is to: Name your methods for what they do public void Repository.SavePerson(Person person) When you save a Person object, you only need to send the Person object Ensure your object has all the properties that are associated with it eg public class Person { public string Id; public string Name; public Image ...


1

Having thought of this for quite some time, I have now come to the same conclusion as the user @Andy. I'm assuming that your Products API would be at least authenticated and authorised. That should prevent rogue clients from creating random product objects in your database. The question now is, whether you should handle the task of generating the ids on ...


Only top voted, non community-wiki answers of a minimum length are eligible