Question: Why a separate project for Controllers?

[wgp...@gmail.com]

Was just checking out Rob Connery's latest post on the Oxite MVC
sample and he notes that the team had made a decision to split the
controllers off into a separate project for the purpose of essentially
making the service layer (you can read it all here:
http://blog.wekeroad.com/blog/some-thoughts-on-oxite/).

Is that what is going on here as well?

I know there has been a lot of discussion regarding the absence of a
services layer and so a couple more questions:

1. Is the plan to use WCF to function as the service layer here? I
talked with a fellow developer where I work and he indicated that
after attending a lecture by Juval that this was the direction MS was
going in.

2. If not, is (or can) the controller's project be considered a
proper place for such logic? I'd agree with Rob in his post that this
blurs the true responsibility of controllers to simply manage
application flow.

3. If then the controller project isn't designed to stand in lieu of
a services layer ... it would seem like this is sorely needed to be
included in the framework.


With all the excitement I've seen previous discussions on a Services
layer generate ... I'm looking forward to the next 400-500 responses
to this post. :)

Thanks - Wayde

[Luis Abreu]

Helo guys.

> 1. Is the plan to use WCF to function as the service layer here? I
> talked with a fellow developer where I work and he indicated that
> after attending a lecture by Juval that this was the direction MS was
> going in.

Well, in my opinion, WCF would be a way of using the services provided by
the model. I only see WCF as thin wrapper and responsible for preparing the
necessary infrastructure needed for my services (ex.: creating the
necessary dependencies and injecting them into the services before they
start doing their work). I guess that you could always put this into your
WCF services, but I do prefer having them separated.

>
> 2. If not, is (or can) the controller's project be considered a
> proper place for such logic? I'd agree with Rob in his post that this
> blurs the true responsibility of controllers to simply manage
> application flow.

As always, it could be. From a theoretical point of view, you should
probably separate them into two different classes: services could be
responsible for coordinating the use of domain objects and controllers would
be consumers of those services. However, if your web app is the only
consumer of your domain, then you could probably merge those
responsibilities into a single class: the controller (personally, I'd always
go with a service layer, but...)

>
> 3. If then the controller project isn't designed to stand in lieu of
> a services layer ... it would seem like this is sorely needed to be
> included in the framework.

Not sure if that would really be necessary. Even if that case, I'm not sure
that you're gaining much by doing putting the controller into a separate
project...are you going to reuse that controller across different web
projects?

>
>
> With all the excitement I've seen previous discussions on a Services
> layer generate ... I'm looking forward to the next 400-500 responses
> to this post. :)

You bet! I've already done my part and sent the 1st message :)

Luis

[Kyle Baley]

I read that too but assuming I understand it correctly, both the Views *and* the Controllers are in a separate project. Not sure what that means though as once you take the views and controllers out, there isn't much of an MVC project left. Maybe he means the views are in one project and the controllers in another?

 

This was the first time I saw the controllers in a separate project too and I see no issue with it. I didn't think of it as moving business logic around or blurring focus. I like it simply because it's easier to test them in isolation. If they are included with the web project, then you need a reference to the web project to test them. I think this was why the RouteRegistrar was moved to the Controllers project.

 

In general, I've been trying to get away from looking at the solution structure as an architectural thing and more of just a way to organize the files. We could theoretically put everything in a single project (or two projects, one app and one test) and use something like NDepend to enforce constraints like "Don't access the data access layer from the controllers". In the absence of such a tool, this way just makes it harder for me to screw up.

[Rodrigo Matias Leote]

The controllers and views separation is useless in my view point, because

the mvc controller is only able to deal with web not any other way of presenting.

I mean you cant change your web view for winforms, for example.

What I'm doing in my project is creating a services project

which will manage every business rule regarding repository access.

Why that? I noticed the business rules and validation should not lie

in the controller, neither in repository. So I've decided to separate

those concerns in a service layer. This way I could change my project's

presenter from Web to WinForms with easy. Such thing cannot be

afforded the way it is in the Northwind sample. Validations are being

made at Controllers level. This way, if you want to change from web

to winforms, you'll have to do every validation again.

Correct me if I'm wrong.

--
Abraço!

Rodrigo Matias Leote
.NET Developer
Dataweb Tecnologia

"Whatever the mind can conceive and believe, the mind can achieve." - Dr. Napoleon Hill

[Luis Abreu]

 
This was the first time I saw the controllers in a separate project too and
I see no issue with it. I didn't think of it as moving business logic around
or blurring focus. I like it simply because it's easier to test them in
isolation. If they are included with the web project, then you need a
reference to the web project to test them. I think this was why the
RouteRegistrar was moved to the Controllers project.
 

Not sure on what that will give me. I've already got my facade ready, so
putting controllers on a different project will only contribute for
increasing the already "bloated" assembly referencing space...

---
Luis Abreu

[Kyle Baley]

You're not wrong but swapping out implementations is not the only reason to move something to another project. Optimizing for the case where you *may* want to swap a web interface for a win forms one is premature at the best of times.

 

I separate to keep things straight in my head and to keep things testable. While I'm developing, I couldn't care less which project a class belongs to. It can be compiled differently for deployment anyway (and should in many cases). I'm on one project now that is moving toward MVC. I.e. It has many web forms now and a handful of controllers. If I had my way, they'd be in a separate project. Not because I want to separate the concerns, but so I can navigate easier. I wouldn't even change the namespace in that case. The build process munges everything into a single assembly anyway.

[Luis Abreu]

afforded the way it is in the Northwind sample. Validations are being
made at Controllers level. This way, if you want to change from web
to winforms, you'll have to do every validation again.

I'm not sure on what you mean by validation...If this is something necessary
for the integrity of the domain then it should be performed in the domain
and not in the controller.

---
Luis Abreu

[Kyle Baley]

Have been polling Twitter on the issue. General (but not overwhelming) opinion is that there is no benefit to having them separate. One person suggested it would encourage people to put business logic in them and start treating them like a service layer. Don't know if I follow that logic. As I said to him, keeping controllers with the web project isn't going to make anyone less stupid.

One person said he keeps them separate just so he could keep the web project locked away in a closet like a red-headed stepchild.

 

Other opinions:

- More projects = longer build times

- Having a reference to the web project from the test project is not a big deal. Tests are not a deployment concern so can reference as much as they have to.

- If they are kept light (as they are supposed to), they should be kept close to the view.

 

It sounds like something that comes down to personal preference in the end. I'll admit, the navigation example I gave earlier is dubious now that I think about it. Especially with a productivity tool like ReSharper or Code Rush. I can see advantages on both sides but my current position is leaning toward, "it doesn't really matter".

[Luis Abreu]

It sounds like something that comes down to personal preference in the end.
I'll admit, the navigation example I gave earlier is dubious now that I
think about it. Especially with a productivity tool like ReSharper or Code
Rush. I can see advantages on both sides but my current position is leaning
toward, "it doesn't really matter".

I really don't see advantages on keeping the mvc project in a closet, but
probably that's because I don't like closets :)

---
Luis Abreu

[DavidHayden]

Personally I would be up for just two projects:

ProjectName.mvc - Views, Controllers, Presentation Model
ProjectName - Domain Model including entities, domain services,
repositories, etc.

and just logically separate your layers/concerns by Namespace.

I think Microsoft advocated numerous assemblies to help people better
separate concerns, but in the end I think it was just a false sense of
security and causes an overly complex solution.


Dave

[Billy]

The result of creating separate, physical assemblies for the logical
tiers has a number of benefits. The first and primary reason is that
it decreases your ability to shoot yourself in the foot. (Kyle noted
this somewhere in this thread.)

Let me tell a war story to illustrate. About five years ago I was
given the privilege to build the most exciting application of my
career thus far with a good sized development team. In developing it,
we tried to emphasize adding complexity and patterns only when
refactoring smells and to keep things as simple as possible (which is
almost exclusively the best route to take). We didn't take any
"prefactoring" steps and let the system evolve organically. A
painfully learned blunder was putting all of the tiers into one
physical assembly and separating them only by namespaces and "team
agreement." The major drawback to this was that every layer was
technically able to communicate with any other layer, even bi-
directionally. (Yes, NDepend could assist, but what happens when you
have to leave a project in another developer's and/or team's hands for
a while?) Inevitably, bi-directional dependencies began to creep into
the code. Progressively, the unit tests, for testing the domain
layer, started becoming dependent on an up to date database and
external services - developers were starting to take shortcuts to the
data layer. Accordingly, the unit tests became slower, more fragile,
and tedious to maintain. This bleeding of one layer into another had
a few ill effects: developers stopped writing and running unit tests
(because they were agonizingly slow to run), the application overall
became increasingly difficult to maintain and difficult to make
modifications without inadvertently affecting various layers
simultaneously, and it became almost impossible to upgrade the data
layer without touching all of the layers of the application. Yes, I
could have done a lot more to prevent some of these problems, both
technically and managerially...but I can't say I've learned as much
from any other project as well! (A computer science professor of mine
once said that you're not an expert until you've made every mistake in
the book...that project almost gave me my expert credentials in one
feel swoop. ;)

All the other benefits of having physically separated tiers really
come out of this story as well:
* It's helpful for being able to unit test logical tiers in isolation,
* It's simple to upgrade your data access layer if only the IoC
depends on it directly,
* It's easier to manage a group of developers which can't violate the
rules, and
* It's easier to understand (aka - maintain) a tier's responsibilities
which have been physically separated from other tiers.

Moral of the story: take necessary prefactoring steps to make
applications easier to unit test and maintain and to make it very hard
for you to shoot yourself in the foot.

Due to these reasons, S#arp Architecture projects have a core domain
layer which *cannot* have concrete dependencies on the project's data
access layer. (Technically, a reference could be added to both
NHibernate and SharpArch.Data from YourProject.Core project, thus
exposing Repository and NHibernate granularities, but that voids the
warranty. ;) Likewise, the controllers layer doesn't have a
reference to the data layer or to NHibernate. A reader on this forum
mentioned in another thread, and I'm paraphrasing, that S#arp
Architecture should reflect the ideals that we want developers to
adhere to. Accordingly, the Visual Studio project template
automatically defines layers in such a way to emulate how the layers
should be used. E.g., YourProject.Controllers knows nothing about the
implementation details found within YourProject.Data; YourProject.Core
has no concrete clue what the persistence mechanism is (yes, it uses
NHibernate Validator...but that has nothing directly to do with
persistence); YourProject.Controllers could care less about which IoC
mechanism you're using or what static properties Global.asax.cs might
be tracking.

(Note that this doesn't mean that additional layers, such as layers
for services or third party dependencies can't be added - either to
their own, dedicated assemblies or to an existing one such as
YourProject.Controllers or YourProject.Core, but that the default
separation of layers provided by the S#arp Architecture Visual Studio
project template serves to demonstrate the minimal, forced separation
of concerns that should be adhered to.)

Contrastly (is that a word?), moving the controllers layer into the
web layer automatically gives it automatic access to all the
references that I've tried to shield it from; references such as
NHibernate and YourProject.Data. Likewise, mashing any other layers
together makes it that much easier for a developer to bleed concerns
from one layer into another, inadvertently as it may be. Certainly,
there's a lot to be said for discipline, team agreement, and tools
such as NDepend to make sure your team is following the rules, but I
feel S#arp Architecture should go a bit further to make it that much
more difficult to make a mess of things. When considering the wide
breadth of skill levels of developers who may be using a development
framework such as this, I'd lean towards enforcing a separation of
concerns by default, and let them void the warranty if they really
want to. ;)

Billy

[Luis Abreu]

>
> Personally I would be up for just two projects:
>
> ProjectName.mvc - Views, Controllers, Presentation Model
> ProjectName - Domain Model including entities, domain services,
> repositories, etc.
>
> and just logically separate your layers/concerns by Namespace.
>

I agree with what you say about using several assemblies for separating
layers/concerns. However, the 2 assembly thingy will only work for simple
cases where your domain is directly consumed by the ASP.NET project.

---
Luis Abreu

[Luis Abreu]

> All the other benefits of having physically separated tiers really
> come out of this story as well:
> * It's helpful for being able to unit test logical tiers in isolation,
> * It's simple to upgrade your data access layer if only the IoC
> depends on it directly,
> * It's easier to manage a group of developers which can't violate the
> rules, and
> * It's easier to understand (aka - maintain) a tier's responsibilities
> which have been physically separated from other tiers.

Agree but only with the option 3 :)

I mean, I agree with the current separation of assemblies on the framework
because one of your objectives is to share the domain model with the final
consumers (this probably isn't really visible on the MVC sample, but if you
had a win forms app with services running you'd see this reuse more easily).
Note: I'm not saying that I agree/like this approach, but it has been the
approach that has been followed by the team since the beginning, right?

In this scenario, yes, repositories should be on a different assembly
because you don't really won't to let your clients (recall the win forms app
example I've pointed earlier) to use them directly (they will probably be
used (directly or indirectly) only by the WCF service that feeds the win
forms apps.

Now, let's say that you do not want to reuse domain objects and that you
want to have them neatly encapsulated on the server side (probably by using
WCF services). In this case, will the repository/core domain separation make
sense? Do I gain anything from it? Well, probably not (unless you have a
really bad team and that's the only way you can make them not understand IoC
- now that I mention this, I do recall that this is really what happens in
where I'm working now :( ).

Too many assemblies can be also a problem, especially when the number starts
growing exponentially...

---
Luis Abreu

[alberto rodriguez]

I have some mixed feeling. I agree that using different projects can
help enforcing some separation between layers (and I think all your
points are really related to this) if you lack a tool that can help
like NDepend, but too many projects means slower compile times too,
and adding complexity to deployments.

[Billy]

For those who wish to merge Controllers with the Web project, this can
easily be done after VS generates the solution structure. You would
then make a small change to the scaffolding generator to have the
generated controller copied to the Web project instead of the
Controllers project location. I'll add a note within the
documentation concerning the steps necessary to do this.

Billy

[alberto rodriguez]

Thanks, that's great. I was thinking if it could be easily done
(without fighting against the tool). I have to confess I haven't yet
tried # myself, although it's been under my radar for some time. Gotta
give it a try. :)