Hi,

I moved my controllers into the business logic assembly where they belong. But to get my MVC running I had to make a little trick: I changed the namespace from my cntrollers to the namespace of the Web Project, otherwise the Views didn't find my controllers. Is there a more elegant way of telling the views where theere controllers are?

 

Thanks, Rainer 

Yes there is a more elegant way of having the views know where the controller is.  Keep the controller in the web project where it belongs.  OK, I don't mean to be a smart ass, but I really can't think why you believe that the controller belongs in the business logic assembly.  Business logic is just that and should be completely testable without regard to a UI or even considerations of a UI.  There might be no UI for example in a webservice.  Controllers in an MVC are used to create UIs.  And in particular the controller in the ASP.NET MVC framework is specifically targeted to the web and as such will include web references that just do not belong in a business logic DLL.

 My 2 cents,

 

Trevor
 

I think you misunderstood the concept of MVC Framework. Your views will never ever know about controllers directly. It should be the other way around, i mean your controller will be aware of your views. you route the paths to your controllers. And if you still want to put controllers to business layer, please take a look at my post: http://forums.asp.net/t/1228179.aspx

I can think of some very legitimate reasons why it would be a good idea to have controllers in a separate assembly. Consider an environment where you have multiple different apps with *completely* different interfaces and UI requirements that share the same Controller logic. In such a case, it would be a VERY valid scenario to put controllers in a separate assembly that could be shared between projects. I'm currently working in such an environment.

aspevia:

"Controllers in an MVC are used to create UIs."

That's a first for me. The "V" in MVC stands for "View" ... which *is* the UI for an MVC application, not the Controller. Unless there is a compelling need to extract it and place it somewhere else (often times, the Model is more appropriate), the Controller *is* where I put much, if not all, of the business logic in my MVC apps.

With that out of the way ... I think the original question is a very legitimate one, and I'd love to know the answer to it.

 

ryexley:

I can think of some very legitimate reasons why it would be a good idea to have controllers in a separate assembly

  putting controllers in a separate assembly wasn't the original question.  It was putting controllers in the business logic assembly where they clearly do not not belong.

 

ryexley:

That's a first for me. The "V" in MVC stands for "View" ... which *is* the UI for an MVC application, not the Controller

As to the question about controllers used to create UIs.  That's what they are for.  Sure the view is the visible UI, but the controller is meant specifically for interacting between the model and the view.  Without the view the controller has no meaning in MVC.  In traditional MVC (before the Web variant of it), the controller handled events from the view.  In that scenario it could easily be argued that a click event while not a "view" is a UI phenomenon and thus the controller while it may not "be" the UI, is intimately involved with it.

 

 

 

aspevia:

putting controllers in a separate assembly wasn't the original question

 

Sorry...I guess I was going by the title of the thread: "How to move the controllers into Businee Logic assembly?" Seems to me to be asking how to put controllers into a separate assembly. 

ryexley:

Sorry...I guess I was going by the title of the thread: "How to move the controllers into Businee Logic assembly?" Seems to me to be asking how to put controllers into a separate assembly. 

 

 

And I guess I should have gone with the spirit of the thread rather than the letter.  Yes it would be nice to know how to put them in a separate assembly.  I'm not sure I need it, but certainly there could be a need for it.

aspevia:

Controllers in an MVC are used to create UIs.

aspevia:

It was putting controllers in the business logic assembly where they clearly do not not belong.

aspevia:

Without the view the controller has no meaning in MVC.

I think you need to do some more reading on the MVC pattern.

wikipedia:

The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.

 

Maybe you are thinking strictly in terms of a "front controller" pattern?  True, they decide which view to use, but that is not their only purpose. 

Their main purpose is to control business logic.  Controllers == Business Logic.  All of my business logic is in my controllers.  All of my controllers are in my business logic assembly.  My controllers assembly is completely independent of my view, and therefore, completely testable independently of the views.  The controller has knowledge of an interface to a view, but doesn't care how the view is implemented.

 

It is kind of hack but it works. It may have side effect, though. The code is just a poc, so feel free to improve it.

davethieben:

Maybe you are thinking strictly in terms of a "front controller" pattern?  True, they decide which view to use, but that is not their only purpose. 

Their main purpose is to control business logic.  Controllers == Business Logic.  All of my business logic is in my controllers.  All of my controllers are in my business logic assembly.  My controllers assembly is completely independent of my view, and therefore, completely testable independently of the views.  The controller has knowledge of an interface to a view, but doesn't care how the view is implemented.

 

That's exactly what I meant and that's the reason why I want them in a seperat assembly, the BizLogic Assemlby that I can test. As I wrote above, it works if you give them the View namespace, but that is an ugly hack.

davethieben:

I think you need to do some more reading on the MVC pattern.

 Thanks for the advice.  It's clear from this thread that we could all use it.

 From your own source (wikipedia):

ControllerProcesses and responds to events, typically user actions, and may invoke changes on the model. Also from widipedia: ModelThe domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model. ie.  business logic.  Business logic belongs in the model.  And again from wikipedia: The controller accesses the model, possibly updating it in a way appropriate to the user's action (e.g. controller updates user's Shopping cart).[3]   

davethieben:

Their main purpose is to control business logic.  Controllers == Business Logic.

  Wrong, wrong, wrong!  The main purpose of controllers has always been to decouple the view and domain by handling interactions from the view and by updating the model.  Go back and look at the original MVC in Smalltalk.  The view in fact instantiated their own controllers.  Now granted todays MVC has changed somewhat and also there are many different implementations of MVC, each varying somewhat, but the view has always been about being the intermediary between the view and the model.  The model (business logic) should be testable on its own without any notion of a view or a controller. A few links:   http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.htmlhttp://www.bud.ca/blog/oh-no-its-mvchttp://moock.org/lectures/mvc/http://wiki.rubyonrails.org/rails/pages/UnderstandingMVC 

 

interesting.  the main point I found in those articles you reference is that no one agrees on how MVC is defined.  (btw, the moock article even claims the model has a reference to the view objects. )

here is my opinion.  take it or leave it.  but I assure you it ain't "Wrong, wrong, wrong!"

I understand many people are okay with having domain logic in model objects, but to me that is scary bad.  how do you unit test that? you certainly can't reuse your model objects.

if the controller has no logic in it, if it just passes through notifications of events, what's the point of it?  a tight coupling between view and controller eliminates the need for a controller. 

what you're describing sounds a lot like ASPX pages with code-behind (tightly coupled view-controller) talking straight to a DAL (model with logic).  that's not MVC to me.

Those of you arguing MVC semantics might want to browse through this forum and read some old posts. This has been discussed quite a few times, and some very good consensus reached. Particularly look for the posts by the people actually creating the ASP.NET MVC framework, as they have some pretty clear ideas what MVC is in general, and what ASP.NET MVC is in particular.

One thing that helps me is getting rid of typical n-tier thinking, particularly "business logic". Business logic is too synonymous with the middle tier in 3-tier design. MVC is different enough from 3-tier that direct correlations don't work very well, and can confuse things all too easily (this thread is the perfect example). So throw Business Logic out, don't give it any place in the terminology.

Here's how I think about it and explain it to others, and it seems to work quite well. In MVC you have Domain Logic and Application Logic. Your Model is your Domain Logic and your Controllers are your Application Logic. If any logic has to do with the application, with routing, making decisions about where to direct the user, what (control) objects to create and correspond with, this is the job of the controllers. If any logic has to do with state, with persistence, with validation, with the domain, this is the job of your model.

The Model should be application-agnostic (which means reuse, sorry davethieben). Controllers are application-specific, and therefore have limited reuse (you wouldn't reuse controllers written for a web application in a Windows application, etc.).

Breaking things out into separate assemblies has all kinds of motivations. Not the least of which is parallel development.

sliderhouserules:

One thing that helps me is getting rid of typical n-tier thinking, particularly "business logic". Business logic is too synonymous with the middle tier in 3-tier design. MVC is different enough from 3-tier that direct correlations don't work very well, and can confuse things all too easily (see this thread for the perfect example). So throw Business Logic out, don't give it any place in the terminology.

Here's how I think about it and explain it to others, and it seems to work quite well. In MVC you have Domain Logic and Application Logic. Your Model is your Domain Logic and your Controllers are your Application Logic. If any logic has to do with the application, with routing, making decisions about where to direct the user, what (control) objects to create and correspond with, this is the job of the controllers. If any logic has to do with state, with persistence, with validation, with the domain, this is the job of your model.

I agree with everything you've said.  However, I think everyone is missing a part, and maybe misunderstanding because of semantics.  In enterprise level applications, you have logic that is determined by the customer.  For instance, the app I'm currently working on has a lot of billing rules.  These rules depend on data points and permissions the user has, what they've come from, where they're going, etc.  I (and everyone I've ever worked with in 10+ years) call these "business rules".  And, I've always lumped all of our business rules into a group called "business logic" (perhaps that is the wrong term, I dunno).  This logic spans many model objects, but is always defined in one Controller.  it's not (the way you've defined it) Domain Logic or Application Logic.  

I'm not saying NO logic in the model, but if you put too much in there, it gets harder to test and reuse, in my experience. 

again, just my opinion.  but this is the way everybody I work with thinks.   

 

sliderhouserules:

The Model should be application-agnostic (which means reuse, sorry davethieben).

not sure why you're apologizing to me, that's the point I was trying to make.