New answers tagged

10

My observation is that WebForms is on the decline. There is a good reason for that. Having used WebForms extensively in the past, it's difficult to do something outside the box. In addition to the learning aspx controls and their proper usage, there is a lot of technical minutiae to learn about the page life cycle when going beyond basics. And in the end, ...


0

If I were you I'd start by utilising the "M" in MVC and abandoning the ViewBag: start creating view models. If you begin by creating a model for your grid sorting, filtering and paging you'll start see where the common functionality is and isn't, i.e. what is specific to a given grid and what is general. You don't have to go to the Repository pattern in ...


8

Yes. Asp.Net Membership is a bit outdated. Asp.Net Identity was introduced a few years ago to help solve some of the pain points with the older system. It supports third party OAuth through Google (and custom OAuth providers), 2 factor authentication, and easily extending the default schema via Entity Framework code first. It's really quite nice out of the ...


1

Do not create tokens in the business layer unless your company's business is security. It can either be its own project or part of the web api. The web api is, after all, the trust border for the application, and the tokens are likely translated (by web api) into user objects for your other layers. Ideally, you shouldn't handling this in your own code at ...


4

Look at the way TicketMaster and similar sites do it. What they do is take the item off the shelf for a brief period of time and start a transaction while the user consummates the payment. If the user fails to complete the payment during that brief period, the entire transaction is cancelled, the item goes back on the shelf, and the user has to start ...


0

There's nothing wrong in your Helper class. I have to confese I use this sort of Utils,Helpers or Holders to make accesible certain resources/logic from different places. However an architect of my company tell me over and over that these classes often gather code that I don't know where to place at. He also dislikes because you could bring components from ...


2

It looks like you are hiding an external dependency to Active Directory using this static class. One problem here is that if you are trying to unit test the class that calls these methods, you cannot fake static calls. So you immediately inhibit the testability of your code. I would refactor this to an interface, something like ...


0

Basically what you did wrong was to copy/paste code. DO NOT copy code. Instead, if you want to reuse code Move the code in a function (this is what functions were invented for). Call the function. There are different opinions on where to put the function (model, service layer, controller, base controller) but that is the icing on the cake - you can ...


0

Consider the programming language you are using (C#) as a set of tools. There is no rulebook, no "should" or "should not". Look at the job are doing, and choose the best tool for the job. If you need a global-available collection of methods, the same for all threads, then static classes are a good tool. If you want to store data within the class (...


0

I might be missing something but to my mind the answer boils down to the methods and member variables. If these are all static, the class itself can (and should be) made static. If not, then it isn't a static class. N.B. there is nothing that forces the class to be static even if the methods and variables are all static.


1

One of the things suggested in Object-Oriented Programming is Bad (the title is to get your attention, and the contents is disputed but entertaining) is that *Handler, *Manager and *Doer classes in general are a code smell that indicate someone trying to force object orientation onto a problem that is better suited for a procedural implementation. In C# you ...


2

I think static classes are nice in many cases. I could just say "use them when it's useful" but that's not very helpful. My rule of thumb is (as always): Am I hiding any dependencies? If you feel like a "helper class" is useful (although beware of low cohesion) then by all means, go ahead. Just make sure your methods don't access global state though. Pure ...


1

A class should be static if it only exists as an abstract concept in your application. For example, say you're creating a clone of Twitter. You may have 2 types of tweets, user tweets and ads. They both share common behavior but are different. Thus, you want to use polymorphism and a factory to create one or another. Those 2 tweets classes should be ...


2

I would argue on the side of the service/scheduled task to update the data. Your web application can become dormant, or unused for a period of time. IIS will at this point put all instances of the worker processes running your application to sleep. Speaking of instances of worker processes. They are completely unaware of one another and having multiple ...


1

In theory, you should only get one instance, unless you made an error in your DI-registration. To check what's happening, just put a breakpoint inside the UnitOfWork-class' constructor. Each time it hits, a new UnitOfWork is constructed.


1

...can you please tell me if I'm doing it right or wrong? Unfortunately, most here would probably disagree that this the right way to structure things. There is a number of issues that I can see: You have no layering to the application, your controller populates the view with result that it, itself, pulls out of the database. Split the logic into layers,...


1

first of all you can move your db context to a separate class and preferably project as well. this class would be your data layer, it should have all the queries in it. You would call them as functions like this (which sould be better named to say what they are getting) model.A = getStrQueryData(EmpId) model.X = getRtsQueryData(EmpId) model.C = ...


3

It's not a question of good and bad. Sometimes it's just necessary. The most common ways are: Define good interfaces between controllers that must communicate and let controllers exchange informations directly: this looks like your approach since one controller provides methods for retrieving jsons from the outside. It's not wrong but i prefer the second ...



Top 50 recent answers are included