1

in a asp.net solution, what would you do to a Model project when you have a Business project?

On the interface, I find it very easy and effective to use an objectdatasource mapped to a class which does all the CRUD. I put that class in side the Business project. The class contains linq queries that gets and sets the data from/to the database.

So what is left to the Model project then? the interface talks to the Business project just fine. Is there anything more or better can be done here?

and here's more question, what is supposed to be in your data access layer then if you use Linq to SQL? only DBML files?

I appreciate you time and effort

Best regards

Rudy
  • 7,008
  • 12
  • 50
  • 85
Mark
  • 11
  • 2
  • Can you clarify whether or not you're talking about ASP.NET MVC? You have both tagged; please tag which one it's applicable to. You wouldn't use an `objectdatasource` in ASP.NET MVC. – George Stocker Jun 20 '11 at 16:46

3 Answers3

1

The commonly accepted best practice is to use the View Model Pattern.

A view model is basically a flattened representation of a business object that corresponds to viewing that business object in a certain context. Instead of passing the business object to the view, the view is rendered in the context of the view model.

While I could explain the implementation in excruciating detail with plenty of code samples, it would be pointless, because Jimmy Bogard already wrote "How we do MVC - View Models. You will have a much better understanding of how to implement this approach, and the reasons for doing so after reviewing that article.

smartcaveman
  • 41,281
  • 29
  • 127
  • 212
0

If you're using ASP.NET MVC, then I'd do the following:

Have a 'local' model that acts as the interface between the BLL and the Controller. Essentially the controller should only know about objects that you use locally.

This will likely involve mapping code in the "repository" part of your Model; AutoMapper is a good example of something to use for that.

There are a few reasons for this:

  1. Your controller isn't directly tied to changes in the BLL.
  2. Dependencies for testing. If you are using the 'One Controller Per Concern' method of building your controller, then you have a lot less dependencies. That becomes somewhat hairy if you're pulling these classes and dependencies in directly to the controller, because then you have to Mock out a lot more and you can have tests fail for reasons that aren't immediately obvious.
George Stocker
  • 57,289
  • 29
  • 176
  • 237
0

You don't NEED anything if you really want it :P. The model folder is mostly put in new MVC projects as a guideline to show how to do separation of concerns with MVC. If your business layer is already in another project, or a different folder, then you can delete it. The folder has no special meaning in the MVC architecture.

KallDrexx
  • 27,229
  • 33
  • 143
  • 254
  • @KallDrexx, the assertion that it has 'no special meaning' in the MVC Architecture is wrong, as I state in my post. – George Stocker Jun 20 '11 at 16:41
  • I specifically said the Model *folder*. That is what I took the vauge question to mean. Otherwise, I have never heard the term "model layer" mentioned otherwise, except as a reference to a business layer – KallDrexx Jun 20 '11 at 16:46
  • The model folder has special meaning in ASP.NET MVC. See the link if my post. – George Stocker Jun 20 '11 at 16:47
  • Yeah sorry I missed that link. I actually did not know about that, and that kind of annoys me. I would like to see the reasoning for `DefaultModelBinders` to have to be in that folder, because it means I have to recreate that folder and futz around with my folder structure for my current projects where I removed it. Thanks for the link! – KallDrexx Jun 20 '11 at 16:48
  • Actually I don't see anything in that link that claims it must be in the Model folder. Did you give the wrong link? – KallDrexx Jun 20 '11 at 16:49
  • The `DefaultModelBinder` doesn't have to be in that folder; but if you want to have the `DefaultModelBinder` bind things for you, the classes you want the `DefaultModelBinder` to bind to have to be in the `Models` folder. – George Stocker Jun 20 '11 at 16:50
  • It's this line: `Model classes, such as Person, Address, or Product`. It uses reflection to determine what to use to ModelBind to, and to do that it looks at all the classes in your Models folder. – George Stocker Jun 20 '11 at 16:51
  • I'm still not seeing where it says it specifically looks in your Models folder. Reflection has nothing to do with physical folder design. – KallDrexx Jun 20 '11 at 16:54
  • @KallDrexx if you do put them in another assembly, and you want to be able to use the modelbinder, then you have to have a mapper (we use AutoMapper) to map the domain objects to the local UI Model, so we can use the DefaultModelBinder where appropriate. I talk about this in my post. It's one way to do it, and it let's you get the 'magic' of the ModelBinder without having to write one yourself. – George Stocker Jun 20 '11 at 16:55
  • After googling around your post is the only thing that I can find that claims you must have your model classes in the `Model` folder in order to perform model binding. Do you have any links that explicitly state this? – KallDrexx Jun 20 '11 at 17:06
  • Also the more I think about this the more it doesn't make sense. None of my entities are in the Models folders or namespace, yet the default model binder seems to bind them perfectly fine without automapper or any other shenanigans. I don't have a Models folder in any of my MVC projects and everything works perfectly fine. – KallDrexx Jun 20 '11 at 17:11
  • @Kalldrexx do you have the [types registered with the ModelBinder](http://stackoverflow.com/questions/3523752/asp-net-mvc-modelbindingcontext-class-how-are-its-model-values-populated)? – George Stocker Jun 20 '11 at 17:15
  • Nope, I have nothing configured in regards to the Model Binder. All I did was create view model classes in my `BL/Models` folder on one project, my `ViewModels` folder in another project, and my `ViewModels` folder in another whole library that is referenced by my MVC app. In all cases posts are being binded correctly with no special configuration being necessary, and I don't see any reason it would be necessary to begin with. It already knows the target type due to the action parameters and can reflect based on that. – KallDrexx Jun 20 '11 at 17:23
  • @Kall I can't retract my downvote unless you edit your answer. Unless you want me to edit it. – George Stocker Jun 20 '11 at 17:43
  • Edited. As a side note I didn't mean to downvote your answer (I just meant to remove the upvote), but I guess I clicked the wrong button to do that. If you edit your post I can remove the down vote. – KallDrexx Jun 20 '11 at 17:45