CODEWITHSUNDEEP
c#repositoryrules
Alex
Alex

Reputation: 2337

Where to put Business Rules on ASP.NET Web App, Repository Pattern

I have been a little confused with trying to determine where to put the business rules for my application.

I am developing an web application using asp.net conventional web forms (not mvc) and on top of that I have a class library where I have the repository pattern for writing to database. I have a "Business Layer" in the repository pattern and also, I am writing stored procedures to affect the tables.

Where should I put for example, Mandatory field validation rules ?

Other example would be, converting foreign currency to USD (i have an exchange rate table, currently I do it in sprocs).

Would you recommend staying away from the sprocs for rules and build everything in my repository business layer ? or In what cases do you recommend building rules and validations within the sprocs ?

Upvotes: 3

Views: 2291

Answers (2)

atiyar
atiyar

Reputation: 8305

  • Your repository is NOT supposed to have a business layer. It's sole purpose should be to act as an abstraction of your database. Inside it you manage how you store/retrieve your application data.

  • Use SP for database operations that are not subject to frequent change. NEVER put your business logic inside SP. Business logic have tendency to change over time.

  • You can create a domain-layer where your business objects reside. Your business object should encapsulate their own validation logic.

  • Other than your business/domain objects you may have utility classes (e.g. CurrencyManager or CurrencyHelper) that actually use your business objects to verify business logic against data.

  • Finally try to keep your domain free from any sort of presentation/view layer reference. Don't apply business validation rules at view layer or display validation logic at domain layer.

-hope that'll shed some light.

Upvotes: 1

oleksii
oleksii

Reputation: 35925

This answer is appropriate if you develop a small application that does not use multiple data sources or does not have an extensively unit-tested business layer and if you do not plan to add a service layer (such as for caching). See the opposition in the comments.

If I may, I can suggest to:

  1. Remove repository pattern completely. Do you really need to support multiple databases?

  2. Keep business logic in a business layer, not database. The benefits are in the locality of the rules. All your domain is expressed as a set of conditions, rules, strategies etc. And it is all located in one place. Should you choose to store them in a database you would create yourself additional headache when maintaining the code.

  3. It is easy to unit test code that is in the business layer. I am not sure if it is possible to unit test SP.

  4. SP and Repository pattern don't go well together.

Currency rate change every fraction of a second, for this you should use a reliable web service that you can call and get a precise value.

Summary:

  • Stay away from SP
  • Stay away from repository pattern
  • Use ORM directly instead of repository pattern abstraction
  • Don't mix persistence and business rules
  • Separate your business rules in a separate (reusable) assembly

Upvotes: 4

Related Questions