I have an ASP.NET MVC application which is using Linq to SQL classes placed in the Model folder.
I want to create some extra classes that I would normally place in my BLL but I'm not sure how to work this with MVC.
With WebForms I would have my DAL as a Class Library.
My BLL as a class library that referenced my BLL.
My Web Site that referenced both the DAL and BLL.
The problem I am facing is, if I create a class library, this will need to reference my MVC Application because it will need to use the types contained in my Model.
If I then add (or try to add) a reference to my class library, I will get a circular dependency.
In Web Forms. My other option would be to place the classes in the App_Code.
Is there an equivalent of App_Code in a MVC application?
You can move all your models to the class library, can't you? Neither MVC or VS mind. This would remove the dependency of the Models library on the Web app.
You can place that in the model folder. As all the business related classed are place into that folder
For better practice see the scottgu the nerddinner examples. He has created the respiratory classes in nerdinner application.
I agree in terms of the Model folder. You can organize it to your heart's content (BLL, DAL, etc.).
I personally would avoid doing a separate assembly unless you have a compelling reason to. Being the kind of developer that tends to over-complicate problems if I'm not careful, I try to follow the KISS (Keep It Simple Stupid) practices as much as possible, which tends to keep me out of a certain amount of trouble.
Try taking a look at S#arp Architecture. You can either use the template they provide or use it as a reference to help you make decisions.
http://code.google.com/p/sharp-architecture/
Related
I am pretty new to mvc but have already read a few books.
What I want to archive is:
-> Having the main asp.net app in its own project.
-> Every modul (for example forum modul) is hosted in a regular dll (including its controller, models and views).
I've looked into the issue of hosting controllers in different assemblies. This is actually easy to handle. But what I do have issues with are the views.
I could not find any resource regarding how to tell mvc that he should look for the views in this namespace the the other view in the other namespace.
Best regards
Simon
Have you imported the projects/assemblies in the project you need to use them?
Look in the References folder. They must be there so you can use them.
I am not quite clear why you would use this style of architecture, but again that's your choice.
What I can confirm is that it is not going to be as useful as you think.
A detailed explanation is here
I want to separate my ASP. NET MVC 5 + WebApi2 solution into separate logical projects, so (in my head) I have:
Data.csproj
references EF6 and handles Code First migrations
Models.csproj
references Automapper
refrences Data (above)
Services.csproj
references Models (above)
Web.csproj
references autofac
references services above
But I can't get my real project to look like that because
Identity sprinkles the model and EF references all over my Web.csproj
When I configure Autofac in Web.csproj and try to register my DbContexts and whatever other dependencies are in my other projects, I will need access to the concrete types, so Web will need to reference all other projects as the DI is setup in Web?
This is a brand new project auto-generated by the ASP .NET template. Thanks.
Generally, you avoid getting your Entity-Framework pollution into your web code by not referencing your data-models in your web project.
If you put interfaces for the models in a separate infrastructure project, for example, you won't have that problem any more. Your 'services' can return abstract types with no dependency on EF and coupling is reduced.
Personally, I like to get around this problem wither with a separate project that is responsible for factory code or (even better IMO) giving each project responsibility for constructing its own objects. Having the factory code in the same place further reduces coupling and can make refactoring easier.
One more thing...
If this is a new project, why do you even need a DI container. You could always use poor man's dependency injection and refactor later when you have a better idea of your needs. They are often overused or used as a crutch to hide overly complex lasagna code. It is an incredibly useful and powerful technology, but most of the benefit in terns of flexibility can also be realised through well designed factories and builders. These can have the additional benefit of increased readability.
I have been working alot on MVC3 now a days and use Dependency Injection ninject etc.
I find it useful in Testing, don't make concrete implementation of classes like Model but instead injected.
My Questions:
How do we explain DI. Any simple definition to it.?
The benefits of DI?
Can we use DI in ASP.NET web forms?
Thanks
Dependency injection is eliminating the objects dependencies of concrete classes.
Benefits:
It allowed to use an abstract interface instead of a concrete class.
This makes lots of (large) applications to be more manageable, if you need to swap out a class, its easier to inherit from an interface and make the IoC container switch to another class.
And if you're looking to use DI in ASP.NET Web Forms in the business logic, yes you can.
Dependency injection means giving an object its instance variables.
Here is a great article about it:
http://jamesshore.com/Blog/Dependency-Injection-Demystified.html.
Can't be simplier, I think.
Benefits: Loose coupling. Easy implementation changes by just editing config file. Easy testing with mocks.
In WebForms? Sure, I've been working on a project where we successfully used Castle Windsor to inject our Repositories.
Brad Wilson has a really good ASP.NET MVC 3 Service Location blog series. It may help you see the value.
Coming from Java programming, I'm used to the general Main<->Test Maven-setup for a project.
Whenever there's a new build, all tests will be run by Maven/Junit and I get feedback about them.
I've been looking around and I can't find an analogue way for ASP.NET and Nunit.
Am I forced to put my UnitTest-classes in the APP_Code folder?
What's the general way to do this? Are there any recommendations for continuous integration?
The best way to architect a TDD-able web app is to put all your code in codebehinds; no inline ASP. Make the controls in the codebehind classes public, and develop your logical operations (bind/unbind, maybe) via TDD. As long as you can see the control and its children from outside the assembly, the unit tests can go anywhere.
Also consider an MVC setup; doesn't have to be the actual MVC framework of .NET, but if you strip down the codebehind to the absolute bare minimum, and perform all your logic in a controller class, then you can provide a mock page/codebehind for unit-testing the controller logic.
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.