Question: I am relatively new to MVC, and have just come across some pre-existing code. 

We have a UserService, which mainly contains CRUD operations, and perhaps, one or two business logic operations - all needed by our controllers. It encapsulates the context and the Membership. 

I was about to implement the ResetPassword operations, but I was not sure where to implement it; whether to implement it at the UserService or at the User Entity. 

---

*UserService*

```
bool ResetPassword(string username, string newPassword);

```

This would lead to my controller being:

```
ActionResult ResetPassword(string username, string newPassword)
{
  userService.ResetPassword(username, newPassword);
}

```

vs

*User*

```
bool ResetPassword(string newPassword)

```

This would lead to my controller being:

```
ActionResult ResetPassword(string username, string newPassword)
{
  var user = userService.GetUser(username);
  user.ResetPassword(newPassword);
}

```

Which approach is recommended?

Answer: 
From your other answers, it sounds to me like the following additional details have cropped up; please let me know if I have these wrong:

1. You're delivering your application as a .jar file,
2. Each customer gets their build directly from you, and there's a small number of customers,
3. You configure a build specifically for each customer, and
4. You don't want your customers to be able to modify their feature access.

In that scenario, I'd store the "active" feature list in a hashed property value stored in a .properties file bound into the .jar. I'll describe one way to do that below. You generate the properties file just before delivery, add the file to the jar:

```
jar -uf applicationJarFile.jar configuration.properties

```

then sign the .jar and deliver it. At runtime, your app can load the properties file, run the hash of each feature, compare with the properties you've stored, and determine which ones are off or on.

Your properties, which determine which features are enabled, might consist of a list like this:

```
feature1=enabled
feature2=disabled
feature3=disabled
feature4=enabled

```

Write yourself a utility which hashes the whole string "feature1=enabled" plus a salt value, e.g. "feature1=enabledaKn087\*h5^jbAS5yt". (There's code for this built into java; see [How can I generate an MD5 hash?](https://stackoverflow.com/questions/415953/generate-md5-hash-in-java), for example.) The result will be an opaque 16-byte number, which you can then store in another properties file to be included in your app: feature1=1865834.... The salt value should be broken into multiple shorter strings in your code so your customer can't just retrieve it and easily duplicate the process themselves.

In your app, at startup, you construct the string above using both the "enabled" and the "disabled" value, run the MD5 of both, and compare it with the stored hash. That'll tell you what features to enable.

I think a separate .jar or .properties is a bad idea; it clutters your delivery.

You can automate the whole process fairly easily, since you can generate the properties on the fly any time, and bind them into your app.

You can add other "baked in" properties which gives you a lot of flexibility in the final deliverable, including things like skinning for customer branding.

As others have pointed out, though: there's lots of ways to approach this, depending on the rest of the details of your product and your overall goals. This is one way to do it, given the assumptions above. AFAIK, there's no "canonical" way to do this sort of thing.
This is very open ended - it really depends on what you're trying to achieve, and what you mean by a feature.

One approach is to use a plugin based architecture. e.g. you have an interface

```
public interface Feature {}

```

and provide each of your ten features as implementors of this interface. Then have some method which runs at application start which looks for `Feature` subclasses on the classpath.

You can control which features a client has by including only the relevant features on the classpath, e.g. using maven.