Tag Info

Hot answers tagged

4

Seems like your login class belongs into a third library that would be referenced by both: the main XYZ and your other smaller libraries. Libraries are like bricks that contain common functionalities. If you feel like you are referencing a library for just one little bit of it, move the bit out, it's obviously common between other libraries as well. Then ...


4

No, no and no It is never appropriate to ignore exceptions like this. As a bare minimum, you should log the exception so that you can figure out what went wrong at a later point. Exception handling isn't sports fishing, you don't catch exceptions for the fun of it. You catch them because you intend to do something with them.


3

Yes and No. Leaving the catch block completely empty ... catch( Exception ) { } ... should be a hanging offence. Having an empty catch block that contains a meaningful, detailed comment about why it's OK to ignore this particular exception (and any sub-classes thereof) might be acceptable, but only in very limited circumstances. Re-throwing the ...


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 don't think you should use them as business objects. According to Vaughn Vernon EF is too inflexible be used directly as business objects Instead use them as state objects. That is wrap them with a better encapsulation of your business logic. In the link I provided he i talking about DDD. What you refer to as business objects are called aggregate roots ...


1

Well, actually you can hide query strings easily in MVC Asp.net without obfuscating. The general idea is to create at least two pathways to the url with the query string. In the pathway(s) you want people to be able to access, create an intermediate method that redirects to the action where you want to return your view. The 2nd pathway will access that ...


1

The problem is. that with the information you give, the range of possible answers is theoretically infinite. If I collect the hard facts I get the following picture: ASP.NET 1.0 Webform DataGrid Tight coupling Dataaccess via custom DAL Besides that, you didn't say in which direction your refactoring is heading. Simply »cleaning the mess« is a good ...



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