I have a very strange situation. I have a UOW Repository pattern. I have domain layer which houses my entities, A Data Access layer which contains the dbcontext (UnitofWork) and repositories for different entities. I have an application layer where i have services which i call for reading and writing data. Architecture contains basically this with some DTOs to help consistency in data. I have a UI layer with MVC5 where i have injected all the dependencies through Unity and it works great if i instantiate each service from a controller constructer.
I have quiet a few services such as GlobalAppSvc (Implemented from IGlobalAppSvc), SystemSettingAppSvc (ISystemSettingAppSvc) etc etc. To make life easier I've created a class called ApplicationManager like this.
public class ApplicationManager
{
public ApplicationManager(ISystemSettingAppSvc systemSettingAppSvc, IBalanceAppSvc balanceAppSvc, IGlobalAppSvc globalAppSvc, IProfileAppSvc profileAppSvc)
{
SystemSettingAppSvc = systemSettingAppSvc;
BalanceAppSvc = balanceAppSvc;
GlobalAppSvc = globalAppSvc;
ProfileAppSvc = profileAppSvc;
}
public ISystemSettingAppSvc SystemSettingAppSvc { get; set; }
public IBalanceAppSvc BalanceAppSvc { get; set; }
public IGlobalAppSvc GlobalAppSvc { get; set; }
public IProfileAppSvc ProfileAppSvc { get; set; }
}
In my Unity i have Registered all the Services and Repositories along with the Unit of Work
container.RegisterType<IUnitOfWork, WUnitOfWork>(new PerResolveLifetimeManager(), new InjectionConstructor());
container.RegisterType<IWUnitOfWork, WUnitOfWork>(new PerResolveLifetimeManager(), new InjectionConstructor());
I have created a BaseController by extending Controller so that i don't have to resolve Application manager in every controller i write. In base controller i am resolving this ApplicationManager as
public class BaseController : Controller
{
// GET: Base
public ApplicationManager ApplicationManager
{
get;
private set;
}
public BaseController()
{
ApplicationManager = UnityConfig.Container
.Resolve<ApplicationManager>();
}
}
I can then go in any controller and extend the controller with this BaseController and i have access to ApplicationManager.GlobalAppSvc.Methods()...
My problem is that whenever there is a data modification such as lets say there is an action which executes to deduct the balance and save changes for a particular user. When i request the user's balance again it is still showing unchanged balance however the balance in Database is deducted but the service is not fetching the updated data. What am i doing wrong?
It looks like the solution is to ensure the BalanceAppSvc needs to be registered with Unity as such:
ApplicationManager=UnityConfig.Container.Resolve<ApplicationManager>(); and registering types as container.RegisterType<IBalanceAppSvc, BalanceAppSvc>(new PerResolveLifetimeManager());
Related
I created a web application and a model. Then I generated a dbcontext class and a database instance. After I built the project, I tried to connect to that database from Server Explorer in Visual Studio, but could not connect.
I tried to test connection but got an error:
This connection cannot be tested because the specified database does not exist or is not visible to the specified user
Whenever I tried to scaffold view or controller I got this error:
Unable to retrieve metadata for ... one or more validation errors were detected during model generation
ModelsTable is based on type TestModel that has no keys defined.
When I created database object in controller class and write query got same error no key defined.
Also made updates on packages and tried again. I think my connection string is correct.
Here is my model.
public class TestModel
{
[Key]
public string ID { get; } = Guid.NewGuid().ToString();
public string AreaName { get; set; }
public bool IsWorking { get; set; }
public string UserName { get; set; }
public DateTimeOffset Time { get; set; }
}
So I could not use scaffolding, Entity Framework and write query.
Here is my dbcontext class.
public class ModelDB : DbContext
{
public ModelDB()
: base("name=ModelDB")
{
}
public DbSet<TestModel> ModelsTable { get; set; }
}
I searched on internet tried founded solutions but did not understand and could not solve. I hope did not ask unnecessary questions. Thanks for your helping.
Are you using Code First? If so I think you need to generate migrations.
In visual studio go to Package Manager Console and run this commands:
Add-Migration "modelClassName"
Update-Database –Verbose
For more information refer to this link: https://msdn.microsoft.com/en-us/library/jj591621(v=vs.113).aspx
You are missing the set; in the field ID.
I'm trying to create an API Module that can be used across multiple API projects. I want the Module to have a controller with an action that can be overriden based on the implementing API requirements.
I have the following project structure:
Module
-Controllers
-ModuleController.cs
-Interfaces
-IModel.cs
-Models
-Model.cs
API
-Controllers
-DerivedModuleController.cs
IModel.cs
public interface IModel
{
int Id { get; set; }
}
Model.cs
public class Model : IModel
{
public int Id { get; set; }
}
ModuleController.cs
[Route("api/module/[action]")]
public class ModuleController : Controller
{
[ActionName("GetModel")]
[HttpGet("{id}")]
public virtual Model GetModel(int id)
{
return new Model() { Id = id };
}
}
DerivedModuleController.cs
public class DerivedModuleController : ModuleController
{
public override Model GetModel(int id)
{
return base.GetModel(id);
}
}
The API project references the Module. If I remove the DerivedModuleController everything works fine. I can make a request to /api/module/GetModel/1 and get a valid result. However, when I add the DerivedModuleController it fails with the following error:
AmbiguousActionException: Multiple actions matched. The following actions matched route data and had all constraints satisfied:
Api.Controllers.DerivedModuleController.GetModel (Api)
Module.ModuleController.GetModel (Module)
Ultimately I want to be able to get a DerivedModel that extends Model from the DerivedModuleController but I can't get past this error.
Is there a way to use the base route (/api/module/GetModel/1) to access the DerivedModuleController and ignore the ModuleController?
I'd appreciate if someone could give an advice on building the right architecture for ASP.NET MVC web app.
I'm currency working on MVC 5 web application, with ADO.NET Entity Data Model which uses existing database. The application mainly uses CRUD operations.
I've doubts on the design pattern I'm trying to use in order to reach loose coupling. I'd also like to use Ninject dependency injector.
So, my solution includes 3 projects: Abstractions, MVCWebApplication and DAL.
I'd like to get a suggestions on structuring the Abstractions project.
Firstly, I've defined the view models for my db entities. I don't use Adapter pattern, instead I'll use AutoMapper to map DB and View model classes:
namespace MVCWebApplication.Models
{
public class CustomerVM
{
public int ID {get; set;}
public string Name {get; set;}
public Contract Contract {get; set;}
}
public class ContractVM
{
public string ContractNo {get; set;} //ID
pulic DateTime AgreementDate {get; set;}
}
}
Generic repository
namespace Abstractions
{
public interface IRepository<T>
{
T Find(object pk);
IQueryable<T> GetAll();
void Insert(T entity);
//...
}
public class Repository<T> : IRepository<T> where T : class
{
public DbContext context;
public DbSet<T> dbset;
public Repository(DbContext context)
{
this.context = context;
dbset = context.Set<T>();
}
//implementation
}
}
And UnitOfWork which gives me an access to the repositories:
namespace Abstractions
{
public interface IUnitOfWork : IDisposable
{
IRepository<Customer> CustomerRepository { get; } //Customer is DB entity
IRepository<Contract> ContractRepository { get; } //Contractis DB entity
//other repositories
void Save();
}
public partial class UnitOfWork : IUnitOfWork
{
private IRepository<Customer> _customerRepository;
private IRepository<Contract> _contractRepository;
private CREntities _context;
public UnitOfWork()
{
_context = new CREntities();
}
public IRepository<Customer> CustomerRepository
{
get
{
if (_customerRepository == null)
_customerRepository = new Repository<Customer>(_context);
return _customerRepository;
}
}
//other repositories, save & dispose ..
}
}
In App_Start I've got:
private static void RegisterServices(IKernel kernel)
{
kernel.Bind<IUnitOfWork>().To<UnitOfWork>();
kernel.Bind(typeof(IRepository<>)).To(typeof(Repository<>));
}
So, my question is this approach expedient? What is the sense of Ninject here?
Thanks a lot
My view on your approach, its nice and there are many people around using it in big applications. So do not worry.
One suggestion, in your above code, you can use IRepository directly instead of using UnitOfWork.XXXRepository. You got generic repository, it will work with any entity (customer, contract, or a new entity)
With having UnitOfWork class the problem is, when you need another repository (for a new entity), you will need to change UnitOfWork class (breaks Open Close Principle).
What is the sense of Ninject here?
I am not sure if I understand your question fully, Ninject is allowing you to set up your dependencies at one single place and then at runtime injecting these dependencies in your controller or services or wherever used.
There is option to create DB which the DB context not allocated in the same MVC project,
i.e create one MVC in project A and the DB context in In project B which can use the model of model A
The reason is that I want to access to the DB from different project without any dependence
Edit.
I've created this in project A and generate the view and controller by scaffold and its working,now what should I do in project B to access to this DB context?
namespace DiffDBContext2.Models
{
public class Ad
{
public string Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
public class AdModelDbContext : DbContext
{
public DbSet<ad> Ad { get; set; }
}
}
I am not sure what do you exactly want. But what I feel is that you want to have data access later as a separate project than your client (mvc). In this case you can have you dbcontext in another project but you need to have connection string in both mvc and data access project. when executing it always request connection string from client.
I have an asp.net website and I would like to organize it into three layers
DataAccess
Domain
UI
What specifically goes in each of these layers?
e.g
Data
- Models
- Repositories? Would that be just interfaces
- IoC?
Domain
- Services?
UI
- javascript
- Area specific models?
- css
Could someone provide a simple guideline for organizing an asp.net website like this?
As other people have said each situation is different, but for a basic architecture, I would probably go along with something like this. It has gotten me out of a few jams and up and running quite quickly.
Infrastructure Layer
This is where all the data access is done. Database connection management, etc.
The Repositories include all queries to the database.
The Dependency Resolution sits here too. Use your DI Container of choice.
Domain Layer
This is where all you business logic sits.
The Domain Services Interfaces are what the UI layer call to use your business logic
UI
Pretty obvious this one....
Code Example
--UI
public class MyController
{
private readonly IMySerivce _myService;
public MyController(IMySerivce myService)
{
_mySerivce = myService;
}
public void MyAction()
{
_myService.DoSomeAction();
}
}
--Domain
public Interface IMyService()
{
void DoSomeAction();
}
public class MySerivce : IMyService()
{
private readonly IMyRepository _myRespository;
public MySerivce(IMyRepository myRepository)
{
_myRepository = myRepository;
}
public void DoSomeAction()
{
_myRepository.Save();
}
}
public interface IMyRepository
{
void Save();
}
--DataLayer
public MyRepository : IMyRepository
{
public void Save()
{
//Manage Save here
}
}
Additionally I usually have a separate area for unit/integration tests.
Update
This most definitely is dependent on your situation. It is very hard to say what method is best without fully understanding what you are ultimately trying to build.
From the list below you can see which method works well for you or fits well with your architecture.
Regardless of which one you choose, your Repository Implementation will have to have a dependency on your Domain Objects project.
Some techniques in doing it include:
No Mapping
Your Domain Objects really then become dummy mappings to your tables. i.e. have a table in your database call User. Then have a Domain Object called User. This is by far the simplest technique.
--Domain
public class User
{
public int Id {get; set;}
public string UserName {get; set;}
public string FirstName {get; set;}
public string LastName {get; set;}
public string Password {get; set;}
}
--Infrastructure
public class UserRepository : IUserRepository
{
public Core.User GetById(int id)
{
return DBConnection.GetByIdQuery(id);
}
}
Mapping
Martin Fowler describes it here
It is possible in your infrastructure layer to have what are known as Domain Transfer Objects (DTO) that represent your database tables. Similar to above, a table called User, a DTO called User. Both having the same properties.
Your domain Entity then becomes a true representation of your domain and business logic.
The mapping of the DTO to your Domain Entity (search query) can be done in the Repository and the mapping of your Domain Entity to your DTO (save/update query) would also be done in your Repository.
To do your mapping you can either create custom mapping classes or use 3rd party tools like AutoMapper. I am a big fan of AutoMapper.
A sample code example would be along the lines of:
--Custom mapper
public class UserRepository : IUserRepository
{
private readonly IUserMapper _userMapper;
public UserRepository(IUserMapper userMapper)
{
_userMapper = userMapper;
}
public Domain.User GetUserById(int id)
{
var DtoUser = GetUserByIdQuery(int id);
return _userMapper.MapUserDTOToDomainEntity(DtoUser);
}
}
public class UserMapper : IUserMapper
{
public Domain.User MapUserDTOToDomainEntity(DataEntity.User dtoUser)
{
//Manual property mapping
}
}
--AutoMapper Example
public class UserRepository : IUserRepository
{
public Domain.User GetUserById(int id)
{
var DtoUser = GetUserByIdQuery(int id);
return Mapper.Map<Domain.User>(DtoUser);
}
}
Other examples include:
https://stackoverflow.com/questions/14724612
There are many many debates out there in blogs and here on SO about the value of DTO's,
including MSDN, this blog and these https://stackoverflow.com/questions/11237946, https://stackoverflow.com/questions/15148866