Should I call BLL methods directly into my Asp.Net MVC 3 Controller?

Question

I have a Business Object Layer that I use in a couple of other applications and I want to use it on my MVC application. My concern is more a design concern: Is it correct to have something like the following:

using Interface.MyOtherProject
public class MyMVCController: Controller
{
    [HttpGet]
    public string GetSomethingById(Int32 id)
    {
        return new JavaScriptSerializer().Serialize(MyObject.GetById(id));
    }

}

So the question would be can I do this, should I do this in the Model instead and return this string directly from the Model or should I rewrite my BLL into my Model. I read some of the answers with similar question but it is not still clear to me if I can or cannot (rather if I should or not). I do not want to break the pattern since I will be showing this project to some companions in school.

Thanks for the help!

Hanlet

score 2 · Accepted Answer · answered Sep 14 '11 at 15:24

2

When we had to confront this decision, we went with creating view models that encapsulated/mirrored our business objects. This gives us more control over how the objects should look when serialized in json without having to add view logic in our business layer.

Example: Suppose we had a Person business object:

public class Person
{
  public int Id {get;set;}
  public string Name {get;set;}
}

When a client is going to consume our web service, we wouldn't want them to know what the Id value is, since that's an internal database key. The two options we considered for fixing that is 1) add a [ScriptIgnore] attribute onto Person.Id property or create a separate view model for our Person, which is custom-tailored to the view domain.

We stayed away from option 1 because we didn't want to add view logic in our business layer for much of the same reason you don't... our business layer isn't directly tied to our presentation layer.

This is a very simplified scenario, but the larger idea is still intact. With separate view models you have the ability to include/exclude data in your view without hampering the cleanliness of your business layer.

answered Sep 14 '11 at 15:24

DMac the Destroyer

5,240
6
36
56

Thanks for the help man. Would this work? `public List MyMethodName(Int32 Id) { List items = new List(); foreach (MyObject obj in MyObject.GetById(Id)) { items.Add(new SelectListItem() { Text = obj.NameProperty, Value = obj.ValueProperty.ToString() }); } return items; } ` In that way I am mirroring my Business Object and also when I serialize this into JSon I do not care about the properties names coming directly from my actual Business Object Thank you! – Hanlet Escaño Sep 14 '11 at 15:38
Sorry for the bad format. I can't figure out how to format the code in here. – Hanlet Escaño Sep 14 '11 at 15:40
That looks like you're trying to serialize your `MyObject` class into a Key/Value pair... in which case you'd probably be better off returning a Dictionary, like so: `MyObject.GetById(Id).ToDictionary(o => o.NameProperty, o => o.ValueProperty)` If this particular case suits all your needs, then I wouldn't pitch a fit, but it still gets around the true value of using view models for your presentation layer. I imagine this approach, if applied universally, would get sticky when it comes to more complex object serialization. – DMac the Destroyer Sep 14 '11 at 18:11
Gotcha! Thanks so much my friend. Although in this particular scenario I really need a SelectListItem object which has a "Selected" property that I can use in my view (I am just filling Dropdowns for now). You have been a great help as well as David. Thank you both! – Hanlet Escaño Sep 14 '11 at 18:19

score 1 · Answer 2 · answered Sep 14 '11 at 14:19

1

I don't see any glaring design concerns here. To address one specific point in the question:

should I do this in the Model instead and return this string directly from the Model

Do you mean should the model provide the JSON-serialized string? I'd say no. The model is just a representation of a business concept and contains the logic which acts upon that concept. The JavaScriptSerializer is basically creating a view of that model. It's UI logic and belongs right where it is, in the presentation code. The model shouldn't care how it's being viewed, it just worries about the state of what it represents.

should I rewrite my BLL into my Model

I'm not sure what you're asking here. The models should contain the business logic, that's for certain. If your BLL is just a bunch of utility methods which use the models as bare DTOs then you might want to look into moving that business logic into the models themselves. But it's hard to tell with the code presented here.

When I see MyObject.GetById(id) I picture that GetById is just a static factory method on the MyObject model which calls any dependencies it needs, such as a DAL repository (maybe supplied by some other means than parameters to the method, but hopefully not internally instantiated), and returns an instance of MyObject, which seems fine. I use that same pattern myself very often, occasionally experimenting with how I name the methods to make the whole thing more fluid.

answered Sep 14 '11 at 14:19

David

208,112
36
198
279

Thanks for your answer. As I mentioned I do use the BLL in some other projects, so it is not a bunch of utility methods, but in fact I have my DAL and Business Logic in it (I use Enterprise Library), so it would not be practical to move the entire BLL into my Model. What I meant with "should I rewrite my BLL into my model" was if I should create all of my Entities into my model and wrap all of their methods and properties from the BLL. Thanks again. – Hanlet Escaño Sep 14 '11 at 14:34
1

@Hanlet: Interesting. I'd be curious to look through the code and see how its organized, but I don't think there's a reasonable format for doing that on Stack Overflow. In terms of high-level general advice, I'd recommend against having both the DAL and Business Logic in the same code. An approach that works well for me is to create my domain models and any service classes (or interfaces for externally-implemented dependency classes) to contain only business logic. My DAL usually ends up being a series of repositories in another project which my models internally use. – David Sep 14 '11 at 14:54
1

@Hanlet: The idea is that the models shouldn't know or care about anything outside of being domain models. Then the applications just interface with the models, not knowing or caring about the DAL or anything like that. The DAL (and other infrastructure dependencies) just implement the domain interfaces, and all code that needs a dependency is written against those interfaces and an IoC framework injects the implementations. – David Sep 14 '11 at 14:56
David, thanks again for taking time to answer my questions. The way I have my BLL organized is by using the Active Record pattern, and using Enterprise Library Data Application Block. So pretty much I could say that they are together but they are not (I might be wrong here). I used to work in a company where we used Rapid Application Development, and this (we found) was the fastest way to develope applications (of course through ORM). I will take your advice. Thanks so much for your help! – Hanlet Escaño Sep 14 '11 at 15:14

Should I call BLL methods directly into my Asp.Net MVC 3 Controller?

2 Answers2