I just finish to implement Repository Pattern & Unit of Work using Ninject Dependency Injection into my asp.net web api project.
Im using Entity Framework as my ORM.
I have the following soluction structure (projects):
Web Application (asp.net web api)
Data (DBContext, Repositories)
Interfaces (IRepository, etc)
Model (POCO Classes from DB)
So for example my PersonRepository (Data project):
public class PersonsRepository : EFRepository<Person>, IPersonsRepository
{
public PersonsRepository(DbContext context) : base(context) { }
public IQueryable<Person> GetByAge(int age)
{
return DbSet.FirstOrDefault(ps => ps.age == age);
}
public void Delete(int personId, int age)
{
// Here I want to validate some stuff before deleting
// Business Rules need to be here!!
var attendance = new Attendance {PersonId = personId, Age = age};
Delete(attendance);
}
}
So my question is if its correct to implement all the business logic inside my Repository Methods? and also what is the best way to return a message or validation in case I need to.
Thanks and appreciate any help!
There should be a new layer between Data and Web called Business. Web will reference Business layer only and Business layer will reference Data layer only. So the Business layer before or after calling the Data layer can implement all its validation and business logic.
No, it isn't. The repository implementation belongs to persistence (DAL). Repository is concerned with 'converting' business objects to/from whatever form used to store them into the database. It isn't its responsibility to care about business logic. Business logic stays in the business layer, in the domain.
Business logic is contained by domain objects and services. It never gets outside the business layer, not in UI (controllers) not in DAL (repositories, EF etc).
The repository implementation you're using is incorrect, an anti-pattern, as it defeats the purpose of a repository: to decouple the business layer from the persistence details (EF is an implementation detail). The repository's interface should never expose details like IQueryable or EF entities. It should 'know' only about business objects.
Your solution structure makes little sense to me: all interfaces you're using should be in the layer they belong to(repository interface is part of business layer, that's why it shouldn't know about EF). The Model, based on your description seems to be the persistence model (it should be part of Data).
You want a Business(Domain) layer where Model really means business model. Not to be confused with persistence model(used by EF), view model(used by a View) or the M from MVC (used by Controllers) :) . The M from MVC refers to parts of the business model but it's not the same thing as the business model.
I suggest to take your time and read a bit more about repository pattern and 3-tier architecture and make sure you've understood the concepts and their purpose.
Related
Straightforward question is: are Microsoft.Extensions.Options.IOptions meant to be used only within the context of umbrella app (web app in this case) or in class libraries also?
Example:
In a n-layered, asp.net core app we have services layer that is dependant on some settings coming from appsettings.json file.
What we first started with is something along these lines in Startup.cs:
services.Configure<Services.Options.XOptions>(options =>
{
options.OptionProperty1 = Configuration["OptionXSection:OptionXProperty"];
});
And then in service constructor:
ServiceConstructor(IOptions<XOptions> xOptions){}
But that assumes that in our Service layer we have dependecy on Microsoft.Extensions.Options.
We're not sure if this is recomended way or is there some better practice?
It just feels a bit awkward our services class library should be aware of DI container implementation.
You can register POCO settings for injection too, but you lose some functionalities related to when the appsettings.json gets edited.
services.AddTransient<XOptions>(
provider => provider.GetRequiredService<IOptionsSnapshot<XOptions>>().Value);
Now when you inject XOptions in constructor, you will get the class. But when your edit your appsettings.json, the value won't be updated until the next time it's resolved which for scoped services would be on next request and singleton services never.
On other side injecting IOptionsSnapshot<T> .Value will always get you the current settings, even when appsettings.json is reloaded (assuming you registered it with .AddJsonFile("appsettings.json", reloadOnSave: true)).
The obvious reason to keep the functionality w/o pulling Microsoft.Extensions.Options package into your service/domain layer will be create your own interface and implementation.
// in your shared service/domain assembly
public interface ISettingsSnapshot<T> where T : class
{
T Value { get; }
}
and implement it on the application side (outside of your services/domain assemblies), i.e. MyProject.Web (where ASP.NET Core and the composition root is)
public class OptionsSnapshotWrapper<T> : ISettingsSnapshot<T>
{
private readonly IOptionsSnapshot<T> snapshot;
public OptionsSnapshotWrapper(IOptionsSnapshot<T> snapshot)
{
this.snapshot = snapshot ?? throw new ArgumentNullException(nameof(snapshot));
}
public T Value => snapshot.Value;
}
and register it as
services.AddSingleton(typeof(ISettingsSnapshot<>), typeof(OptionsSnapshotWrapper<T>));
Now you have removed your dependency on IOptions<T> and IOptionsSnapshot<T> from your services but retain all up advantages of it like updating options when appsettings.json is edited. When you change DI, just replace OptionsSnapshotWrapper<T> with your new implementation.
I build a web app using sails.js and I have few questions about the design of the app:
Should I create controllers for each page, component, or model? I saw in the documentation and at some tutorials that they create controllers for each model. That looks nice but if I have a complex page/component and I want to create view with multi models (and data) it doesn't help me.
Where should I put the business logic part of a component or feature? I read about Serivce but I'm not sure that this is the right place.
To sum up, I saw that in sails the code is arranged like the models (you have model, controller and view for each model) but what if I want to arrange it by features or components or pages?
Thanks!
Basically you should have Controller for each Model (but if you don't need specific controller and it would be empty you don't need to create it). It's just a good practice to have a Controller for each Model.
If you use some part of code in many places and it is not connected with one specified Model it should be Service (like sending emails, notifications, logging, images processing). Read about DRY
Controller should be as simple as possible. It should contain call of Model and Service and callback with rendering output. All business logic should be in Models.
I created some additional 'helper' Models for more complex Models like Users or so to make Classes bit shorter.
To sum up. Core of your application is Model. It's not only responsible for database layer, bur also business layer of your app. Later there is Controller. It gets data from Model and it passes it to Views which is responsible for presentation of data taken from Model.
Answer to First
Sails is for REST API it has nothing to do with view.
you just need to know what MVC is and what REST is....
In one Controller you can invoke multiple models or one model can be invoked in multiple controllers.
In one page you can fetch data from two different API's which may be from different controller or Even they can be of different server.
for Example:
In the page you are getting data directly from ellasticsearchAPI(say esAPI1)
You are getting data from sails API(sAPI1).
You are getting data from other sails API(sAPI2).
Answer to Second
For neatness you should try to keep controller as clean as possible. So for the same sailsJS provide you services. Where you can write Common functionalities which are to be used in multiple controllers.
See the codes for example
Codes
here is the controller:
//TestController
module.exports = {
action1:function(req,res){
Model1.find().exec(function(err,data1){
if(err)
return res.negotiate(err);
res.ok(data1);
});
},
action2:function(req,res){
Model2.find().exec(function(err,data1){
if(err)
return res.negotiate(err);
res.ok(data2);
});
},
action3:function(req,res){
var hash=SomeService.getMeHashCode(req.query.text)
res.ok({hashedData:hash});
}
};
And this is service.
//SomeService.js
module.exports = {
getMeHashCode:function(strinToBeHashed){
var hash=doSomeThingToHash(strinToBeHashed);
return hash;
}
};
I've been running into endless problems attempting to use Windsor with Web API and injecting HttpRequestMessage into downstream dependencies of a controller. Since I've tried all the matching answers on Stackoverflow, I'd like to ask the question in a different way:
In Castle Windsor, how can I resolve a component instance while supplying a value for a downstream dependency? That is, the supplied value is required by a component that is required by the component being resolved.
For context, I'm trying to inject HttpRequestMessage so that I can use it to resolve the request context (primarily to resolve an absolute URL).
Edit I'd also like to point out that I don't currently have a dependency on Web Host / System.Web and I'd rather not change that.
A proper approach is to
Create IMyDesiredRouteParameterProvider
Implement it. Get the current request inside it and get the url
Register it and inject it in the desired dependent class via constructor.
I made myself such an implementation and I can say that this way it works fine. You can make Web.Infrastructure assembly and put the implementation there. Or put both the interface and the implementation there if you are going to reference it from another web module.
using System;
using System.Web;
namespace RouteParameterProvider
{
interface IMyRouteParameterProvider
{
string GetRouteParameter();
}
public class ControllerActionMethodRouteParameterProvider : IMyRouteParameterProvider
{
public string GetRouteParameter()
{
string Parameter = HttpContext.Current.Request.RequestContext.RouteData.Values["controller"] as string;
if (string.IsNullOrEmpty(Parameter))
{
throw new InvalidOperationException();
}
return Parameter;
}
}
}
You can get every possible thing that the Request Context contains from :
HttpContext.Current.Request.RequestContext
And it will be better if you rethink your design decision :
I need HttpRequestMessage to be regstered prior to creating each
instance of SomethingController so that it will be available down at
the LinkGenerator layer.
Containers are to be initialized at runtime and then used to resolve.
I need HttpRequestMessage to be regstered prior to creating each
instance of SomethingController so that it will be available down at
the LinkGenerator layer.
It sounds like you want to register an item with the container at runtime, post-startup. In general, this is not a good practice--registration should be a discrete event that happens when the app is fired up, and the container's state should not be changed during runtime.
Dependency Injection is about resolving service components, not runtime state--state is generally passed via methods (method injection). In this case it sounds like your LinkGenerator component needs access to the ambient state of the request.
I'm not that familiar with HttpRequestMessage, but this answer seems to show that it is possible to retreive it from HttpContext.Current. You could make this a method on your LinkGenerator class, or wrap this call in a separate component that gets injected into LinkGenerator (HttpRequestMessageProvider?). The latter would be my preferred method, as it allows LinkGenerator to be more testable.
Given the lack of a clean way of doing this and Web API not providing information as to the hosted endpoint beyond per-request context objects, I ended up injecting the base url from configuration.
Is this library by Mark Seemann the answer? In the description he writes explicitly :
This approach enables the use of Dependency Injection (DI) because the
request can be injected into the services which require it.
Then gives an example :
// Inside an ApiController
var uri = this.Url.GetLink(a=> a.GetById(1337));
By which you can then pass the URL down the road in the service that you have injected in the controller.
UPDATE :
Mark Seemann wrote about the same exact problem here:
"Because HttpRequestMessage provides the context you may need to
compose dependency graphs, the best extensibility point is the
extensibility point which provides an HttpRequestMessage every time a
graph should be composed. This extensibility point is the
IHttpControllerActivator interface:..."
This way you can pass request context information to a component deep in the object graph by getting from the HttpRequestMessage and passing it to the DI container.
Just take a look at the interface of IHttpControllerActivator.
The WEB API framework gets the IHttpControllerActivator through DependencyResolver. You probably already replaced it by your CastleWindsorDependencyResolver. Now you have to implement and register your HttpControllerActivator and register it.
When the WEB API framework gets IHttpControllerActivator from DependencyResolver (your Castle Windsor DR) and calls IHttpControllerActivator.Create() it will pass you the HttpRequestMessage. You can get your info from there and pass it to the your CastleDR before you call Resolve(typeof(MyController)) which will resolve the whole object graph - that means you will have MyHttpContextInfo to inject in your XYZComponent deep in the resolution stack.
This way tou are passing the arguments in the last possible moment but it is still possible. In Castle Windsor I make such passing of arguments though CreationContext.AdditionalArguments["myArgument"];.
I have created the following classes for sharing images. They implement an interface, but I need a way of switching between them with user interaction. I've done it the following way:
As you can see, service 1 and service 2 implement iSharingServices, and inherit from PolimorphSharing.
PolimorphSharing is simply and an abstract class that implements the methods I want public from Service 1 and Service 2. Those methods will then be overridden on the Service 1 and Service 2.
Because I need a way to switch the service in runtime, I've created a gateway class that inherits from PolimorphSharing. I can then call it the following way:
private var sharingService:PolimorphSharing = new SharingServicesGW('svc1').createService();
This all works flawlessly, and I can now switch between services with no problem whatsoever. However, I feel there's something wrong about it, so I would like to ask you guys for some advice on how to better implement this.
Any opinions here would be appreciated. I feel like I'm kind of implementing the factory pattern here the hard way.
UPDATE:
Just adding some more insight to this. Basically the idea here is for my client to be able to upload images with various different public sharing services such as imageshack, imgur etc. I want my client to be able to select the service in which the image is to be published to (hence the "switching between them with user interaction" bit of the question.
The method that does the uploading bit, is requestShareImage(), processResults() simply turns whatever gets returned to a unique format, so my client can read off it always the same way. getObject() is my accessor, and onIOError will handle exceptions with any of the public API's
Thanks all in advance,
SharingServicesGW IS a factory. However, there's no need for it to - and it shouldn't - inherit from PolimorphSharing. Also you're doing it a bit skewed. The client should be using objects of the interface type, not the abstract type.
Your interface should be defining the public API, not your abstract base class. In fact in AS3 interfaces can only define public members, while pseudo abstract classes can enforce implementation of protected members.
-- EDIT --
here's a UML diagram of how I would do it
I have a ASP.NET MVC3 solution named "SampleProject". I have 4 projects in the solution.
The project names of the solution are
SampleProject.Data (holds entity classes, DAL classes, and filter classes)
SampleProject.Service (something like BLL in standard ERP)
SampleProject.Tests (test project)
SampleProject.Web (holds controllers and views)
I am calling the Service classes from my controllers. The service classes are calling Data classes and data classes are performing the database operations.
I have done create, list and details part. Now I stucked in Edit part. None of the examples (NerdDinner,MVCMusicStore etc) using my architecture. In the provided examples(NerdDinner,MVCMusicStore etc or in ASP.NET website tutorials), they are just using built in UpdateModel method which I don't want to use. I want to manually get the model object from my view and send it to my Data layer for update.
My question is, how can I update the models through different project layer?
I solved the porblem. Here is the code.Just for reference, CResult is a class which contains IsSuccess(bool), Message(string) properties in it.
CResult oCResult;
[HttpPost]
public ActionResult Edit(Restaurant model)
{
try
{
oCResult = restaurantService.Update(model);
if (oCResult.IsSuccess)
{
return RedirectToAction("Index");
}
return View("Error");
}
catch
{
return View();
}
}
The view engine prepares the object (in my case, it is Restaurant type of object) it inherits with new values and send back to controller. this is my understanding.