separation-of-concerns

I'm trying to implement a repository solution for Entity Framework but I am having trouble registering the types that include generics using Unity. Given: // IRepository interface public interface IRepository<TEntity> { // omitted for brevity } // Repository implementation public class Repository<TEntity, TContext> : IRepository<TEntity>, IDisposable where TEntity : class where TContext : DbContext { // omitted for brevity } // service layer constructor public MyServiceConstructor(IRepository<Account> repository) { _repository = repository; } I need to register the type mapping for IRepository

And what do you put in your View? A recent blog from Scott Hanselman about using a special model binder for easier testing led me to think about the following: What do you put in your controller logic building the view model, and what should be put in the view? what he does is this: var viewModel = new DinnerFormViewModel { Dinner = dinner, Countries = new SelectList(PhoneValidator.Countries, dinner.Country) }; return View(viewModel); Now, I use the same way of passing data to my view, but I am unsure about how he deals with the Countries property. You could argue both sides: Wrapping the

I am building an applications in .net/c#/Entity Framework that uses a layered architecture. The applications interface to the outside world is a WCF service Layer. Underneath this layer I have the BL, Shared Library and the DAL. Now, in order to make the business logic in my application testable, I am trying to introduce separation of concerns, loose coupling and high cohesion in order to be able to inject dependencies while testing. I need some pointers as to if my approach described below is good enough or if I should be decoupling the code even further. The following code snippet is used to

Every article found in the Internet on using ViewModels and utilizing Automapper gives the guidelines of the "Controller -> View" direction mapping. You take a domain model along with all Select Lists into one specialized ViewModel and pass it to the view. That's clear and fine. The view has a form, and eventually we are in the POST action. Here all the Model Binders come to the scene along with [obviously] another View Model which is [obviously] related to the original ViewModel at least in the part of naming conventions for the sake of binding and validation. How do you map it to your Domain

I've read some MVC advice in the past regarding models stating that you should not reuse the same model objects for the domain and the view; but I haven't been able to find anyone willing to discuss why this is bad. It is my opinion that creating two separate models - one for the domain, one for the view - and then mapping between them creates a lot of duplication, plus tedious mapping code (some of which might be alleviated by things like AutoMapper ) that will likely be error prone. What makes having a separate model for the two concerns worth the trouble of duplication and mapping code? At

I refer to ServiceStack documentation reg use of POCOs: Since it promotes clean, re-usable code, ServiceStack has always encouraged the use of code-first POCO's for just about everything. i.e. the same POCO can be used: In Request and Response DTO's (on client and server) In JSON, JSV and CSV Text Serializers As the data model in OrmLite, db4o and NHibernate As the entities stored in Redis As blobs stored in Caches and Sessions Dropped and executed in MQ's services" I love servicestack & how easy it is to write web services with it. I am trying to understand how best to setup my project & not