Tag Info

New answers tagged

1

I prefer this structure: MyApp.Web // UI MyApp.Core // Context MyApp.Domain MyApp.Service MyApp.Api // WebAPI MyApp.Utility // it's depended on your case !, I didn't use this layer so far. If you use DI in your project, you should use Custom Controller Factory, so I prefer WebAPI as separated layer and create specific Custom Controller Factory, instead ...


1

You should absolute not put it in the data layer. That would be weird because none of the dependencies you need for web api are, and should not be, present in the data layer. It is fairly common to have mixed mvc and web api into the same assembly and it has the advantage that deployment is easier. If you want a more clean approach. Clean in the sense that ...


-1

I encourage you to build your own site or start converting your all projects into a web-based one, that's why it is called web development. We need to be familiar with its front-end and back-end, you can also include the database to be a full-stack developer.


-1

I think that using Compare will solve your problem. You can try using an equation where you can make sure that the user input is != to the questions that you already have.


1

I'm going to disagree with the commenters who say this question is overly vague or broad. The explanation of the question may be so, but, the question as stated in the title has a clear and obvious answer, which is no, there is no standard way. Speaking in general terms, you will need a task object and likely a set of objects which inherit that object. ...


1

I'm assuming that this isn't the best practice as the smart but naughty user could loop through all the possible combinations of the PIN code and wait which one will give him true as a response. This is called a "brute-force" attack. In principle, it is impossible to prevent brute-force attacks. There is simply no way to set up a password scheme that ...


0

There are good answers here. I post this as a partial answer; it would perhaps be better as a comment. However sticking the same comment on numerous posts is not good. One cannot claim YAGNI is a reason for not creating an API. The API is a natural and logical testing endpoint. Thus right from day 0, there are two applications that use the API: the UI and ...



Top 50 recent answers are included