Tag Info

New answers tagged

0

I would not extend POCOs to use them as business objects. It will mix domain logic with data logic and the codes become very difficult to maintain in the future. But you also mentioned you will not have unit testing. So maybe you are building some one-off, short-lived project that does not need to be maintained and then it may be Okay. Just remember it may ...


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

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 ...


-2

Today, a web-based application is not enough to reach it's customers. People are very smart, they are using iphone, mobile, tablets etc. devices in its daily life. These devices also have a lot of apps for making the life easy. Actually, we are moving from the web towards apps world. So, if you like to expose your service data to the browsers and as well as ...


0

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 ...


0

If a property is dependent only on the User, then it belongs on User; if it depends only on a Role, it belongs on Role. Clearly, if it depends on both User and Role, it belongs on a class that models the intersection of User and Role, i.e. something like Profile. A user can have many profiles; many profiles can refer to the same role, so it's just a normal ...


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 ...


0

What are those role-dependent attributes? That's strange for users to have different sets of attributes, since they can change roles in a blink. What will you do with the attributes from role A when user no longer has the role? Delete them? What if tomorrow that user will change his role back to A? So, one approach is to maintain a single overly-bloated ...



Top 50 recent answers are included