I have a vs2010 solution with many project (WPF control library, some business logic etc.)
Currently each library reach the WCF data services using his own Service Reference.
I'm trying to write a new library that will a some kind of a DL to the WCF data service, I want to write it using templates - so I don't need to write the same function to all my entities (~30).
Well I'm getting nowhere..
I started by add a simple Interface like this:
public interface IRepository<T>
{
IQueryable<T> GetAll();
T GetSingle(int id);
IQueryable<T> FindBy(Expression<Func<T, bool>> predicate);
IQueryable<T> Where(Expression<Func<T, bool>> predicate);
void Add(T entity);
void Delete(T entity);
void Update(T entity);
}
I'm trying to implement the interface and I came into issues I have no Idea how to solve
1) in the implementing class how do I tell my context which entity I'm querying
public IQueryable<Region> Where(Expression<Func<T, bool>> predicate)
{
return _context.(something general).Where(predicate);
}
2) Even if I provide the entity
public IQueryable<Region> Where(Expression<Func<T, bool>> predicate)
{
return _context.Region.Where(predicate);
}
I came into casting issues I didn't manage to solve.
well, that's about it.
Thank you
I've been experiencing by the very same problem: it is not possible to declare a WCF contract with open generic types (nor interfaces, by the way). The problem is that this framework does not adhere to some basic good OOP principles and, thus, it causes some frustration to experienced programmers.
For more information about this issue, see the example at msdn.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am developing a new WebApi using .NetCore2.2, Autofac4, Dapper. There are few very basic questions because this is my first WebApi project. As part of this project I have to write both unit-test and integration-test.
My questions are as follows (Sample Code is give below):
What is recommended return type between "Task< IActionResult >" and "Task< IEnumerable >"?
Recommended object Scope of the dependencies in startup class for my project?
Do I really need UnitOfWork for this given project structure?
What are the flaws if I follow this design?
Is there any better way to design this API?
As TDD do I need write test cases for API layer(Controller) and Infrastructure layer only or Doman Layer (it doesn't have any logic) as well?
What are the scenario I must include in my controller unit test?
Domain Layer:
[Table("Movie")]
public class Movie
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int ID {get;set;}
public string Title {get;set;}
}
public interface ICommandRepository<T> where T : class
{
Task CreateAsync(T entity);
Task UpdateAsync(T entity);
Task DeleteAsync(T entity);
}
public interface IQueryRepository<T> where T : class
{
Task<IEnumerable<T>> GetAllMoviesAsync();
Task<IEnumerable<T>> GetMoviesByTitleAsync(string title);
Task<T> GetMovieByIDAsync(int id);
}
Infrastructure Layer:
public class MovieCommandContext : DbContext
{
public MovieCommandContext(DbContextOptions<MovieCommandContext> options)
: base(options)
{}
public DbSet<Movie> Movies { get; set; }
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
}
}
public class MovieQueryContext : IDisposable
{
private readonly IDbConnection connection;
public MovieQueryContext(string connectionString)
{
connection = new SqlConnection(connectionString);
}
public async Task<IEnumerable<Movie>> GetAllMovies()
{
// Use Dapper->QueryAsync
throw new NotImplementedException();
}
...
public void Dispose()
{
if (connection?.State == ConnectionState.Open)
connection.Close();
}
}
public class MovieCommandRepository : ICommandRepository<Movie>
{
private readonly MovieCommandContext context;
public MovieCommandRepository(MovieCommandContext dbContext)
{
context = dbContext;
}
public async Task CreateAsync(Movie movie)
{
await context.AddAsync<Movie>(movie);
await context.SaveChangesAsync();
}
public async Task UpdateAsync(Movie movie)
{
var entity = context.Attach<Movie>(movie);
context.Entry<Movie>(movie).State = EntityState.Modified;
await context.SaveChangesAsync();
}
public async Task DeleteAsync(Movie movie)
{
context.Remove<Movie>(movie);
await context.SaveChangesAsync();
}
}
public class MovieQueryRepository : IQueryRepository<Movie>
{
private readonly MovieQueryContext context;
public MovieQueryRepository(MovieQueryContext dbContext)
{
context = dbContext;
}
public async Task<IEnumerable<Movie>> GetAllMoviesAsync()
{
return await context.GetAllMovies();
}
public async Task<IEnumerable<Movie>> GetMoviesByTitleAsync(string title)
{
return await context.GetMovieByName(title);
}
public async Task<Movie> GetMovieByIDAsync(int id)
{
return await context.GetMovieByID(id);
}
}
API Layer:
[Route("api/sample")]
[ApiController]
public class SampleController : ControllerBase
{
private readonly ICommandRepository<Movie> movieCommand;
private readonly IQueryRepository<Movie> movieQuery;
public SampleController(ICommandRepository<Movie> command, IQueryRepository<Movie> query)
{
movieCommand = command;
movieQuery = query;
}
[HttpGet]
public async Task<IActionResult> GetMoviesAsync()
{
try
{
var movies = await movieQuery.GetAllMoviesAsync();
return Ok(movies);
}
catch
{
// TODO: Logging
return BadRequest();
}
}
[Route("{name:alpha}")]
[HttpGet]
public async Task<IActionResult> GetMoviesByTitle(string movieTitle)
{
try
{
var movies = await movieQuery.GetMoviesByTitleAsync(movieTitle);
return Ok(movies);
}
catch
{
// TODO: Logging
return BadRequest();
}
}
[Route("{movieID:int:min(1)}")]
[HttpGet]
public async Task<IActionResult> GetMovieByID(int movieID)
{
try
{
var movie = await movieQuery.GetMovieByIDAsync(movieID);
return Ok(movie);
}
catch
{
// TODO: Logging
return BadRequest();
}
}
[Route("")]
[HttpDelete("{id:int:min(1)}")]
public async Task<IActionResult> Delete(int id)
{
try
{
var movie = await movieQuery.GetMovieByIDAsync(id);
if (movie == null)
return BadRequest();
await movieCommand.DeleteAsync(movie);
return Ok();
}
catch
{
// TODO: Logging
return BadRequest();
}
}
}
Startup.cs:
private void ConfigureContainer(ContainerBuilder builder)
{
var contextOptions = new DbContextOptionsBuilder<MovieCommandContext>()
.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))
.Options;
builder.RegisterType<MovieCommandContext>()
.WithParameter("options", contextOptions);
builder.RegisterType<MovieQueryContext>()
.AsSelf()
.WithParameter("connectionString",Configuration.GetConnectionString("DefaultConnection"));
builder.RegisterType<MovieCommandRepository>().As<ICommandRepository<Movie>>();
builder.RegisterType<MovieQueryRepository>().As<IQueryRepository<Movie>>();
}
Point 1:
You should return an IActionResult to return a propper Http response, instead of returning the Task<IEnumerable<Movie>>. That way you guarantee the S and the I of SOLID principles
Point 2 & 3:
see here: Entity Framework Core service default lifetime
Point 4:
IQueryRepository as some bad methods names. The names are tight coupled with domain concepts and they should not.
You are failing the Separation of concerns ( the S of SOLID).
ICommandRepository as an Add method that is being expose to some controller and not being used ( same as Update) here you are failing on the Interface segregation.
MovieQueryContext does not implement IDisposable pattern correctly please see here!
MovieQueryContext is different from MovieCommandContext on the way it initializes. Why? You should try to be coherent the way you design you types because it will give you reusability and apply the DRY principle.
Consider the effort you will need to to if the access to the database change to mongodb. Or if the access to the database changes to a remote service How many changes, and where do you do does changes to support that?
If Movie is a Domain Type it should not have attributes to any specific database access. keep it POCO as possible.
Point 5:
To design your API consider this post. The way you inject your dependencies should consider the lifetime of those objects. Keep in mind that in aspnet.core ApiControllers lifetime is per request. The way you manage your resources to access database should take that into consideration.
If you are considering CQRS, the controllers should be diferent. Keeping in mind the Separation of concerns regarding those responsabilities. One controller would have the responsability to expose some query API, and the other to process commands. There are good frameworks to support CQRS see this scott hanselman post.
Constraints exists on Route attribute not on Verbs.
Logging and Exception handling should be done on an ActionAttribute or on some Especific Middleware, because they are considered to be cross cutting concerns.
Delete Action does not comply to the Http protocol. please consider http rfc:
GetMoviesByTitle Action does not have the name parameter.
Point 6:
Unit tests should test business logic, mocking all the external dependencies with values relevant to the test in place. TDD methodology considers 3 main steps ( here for more details):
the first step consists on implementing the unit tests so it fails
Iterate on implementation of the method being test until it passes with success
Improve the implementation of the method being test
If you want to test your ApiController as being used with all the middleware integrated you need to have that environment put in place without using an actual server that open ports. To do that please consider the usage of TestServer ( see here and here )
1. What is recommended return type between "Task< IActionResult >" and "Task< IEnumerable < Movie > >"?
Even though the API allows you yo use the interface IActionResult, I wouldn't use it at all. Why? Semantics, the only way to know what the true return is, is to see the implementation. It's clearer if the returns is Task< IEnumerable< Movie>>.
If you need to throw a BadRequest or other http code, use the asp.net pipeline to handle this for you. See Notes below.
When using whatever tool to generate some sort of documentation of this API it won't help hiding the real result.
2. object Scope of the dependencies in startup class for my project?
Avoid sharing state between calls, to avoid future issues with synchronization just stick to scope dependencies per request. This may be a performance issue if you have a lot of requests, you can always change this later on. If it's an issue at all.
3. I really need UnitOfWork for this given project structure?
4. What are the flaws if I follow this design?
5. Is there any better way to design this API?
In hope of answering the above 3 questions. The problem I see is extending the functionality around Movie model. e.g. add a fourth action on ICommandRepository.
It seams it will grow vertically. It will only be a problem if multiple classes implement this interface, because they will all need to change. (Interface Segregation Principle)
A way to solve this is to use the Mediator pattern. Your controller will receive the mediator and the mediator will deliver the message to whoever handles it. With this type of solution you could have a class per operation and therefore your system can grow horizontally as new classes are added to the system. (Open Close Principle)
In time, you'll see that a lot of functionality can be reused and adding features is just a matter of configuration.
6. As TDD do I need write test cases for API layer(Controller) and Infrastructure layer only or Domain Layer (it doesn't have any logic) as well?
The idea of Testing in general is to test behavior, when TDDing that should be your mindset. In my experience I found that testing the whole behavior is better than multiple parts of the same behavior.
In this case, the API Layer is part of the infrastructure as is the persistence layer. They should have their own tests, the business rules (Application layer) should have their own tests. The application layer is what you want to last forever. The Api will change as technologies appear (windows forms, web forms, web apis, etc.) Regarding databases as well, you don't know if you want to stick with EF forever.
If the domain layer doesn't provide any behavior then there is nothing to test.
7. What are the scenario I must include in my controller unit test?
I would test using asp.net TestHost:
https://learn.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-2.2
Test the if routing is correct, test failing scenarios and successful scenarios.
Some notes:
An exception in the Controller does not mean a BadRequest.
Logging is a cross cutting concern, don't just do it everywhere.
Either use the asp.net pipeline or just move this concern to
application layer.
It appears that MovieQueryRepository does nothing, so you don't need it.
This is just some remarks about your questions, there is much more to it. Just remember to keep things simple and organized.
Hope it helped, let me know!
Is instance of Feign thread safe...? I couldn't find any documentation that supports this. Do anyone out there think otherwise?
Here is the standard example posted on github repo for Feign...
interface GitHub {
#RequestLine("GET /repos/{owner}/{repo}/contributors")
List<Contributor> contributors(#Param("owner") String owner, #Param("repo") String repo);
}
static class Contributor {
String login;
int contributions;
}
public static void main(String... args) {
GitHub github = Feign.builder()
.decoder(new GsonDecoder())
.target(GitHub.class, "https://api.github.com");
// Fetch and print a list of the contributors to this library.
List<Contributor> contributors = github.contributors("netflix", "feign");
for (Contributor contributor : contributors) {
System.out.println(contributor.login + " (" + contributor.contributions + ")");
}
}
Should I change this to following... Is it thread safe...?
interface GitHub {
#RequestLine("GET /repos/{owner}/{repo}/contributors")
List<Contributor> contributors(#Param("owner") String owner, #Param("repo") String repo);
}
static class Contributor {
String login;
int contributions;
}
#Component
public class GithubService {
GitHub github = null;
#PostConstruct
public void postConstruct() {
github = Feign.builder()
.decoder(new GsonDecoder())
.target(GitHub.class, "https://api.github.com");
}
public void callMeForEveryRequest() {
github.contributors... // Is this thread-safe...?
}
}
For the example above... I've used spring based components to highlight a singleton. Thanks in advance...
This discussion seems to suggest that it is thread safe. (Talks about creating a new object being inefficient)
Had a look at the source and there doesn't seem to be any state that would make it unsafe. This is expected as it is modelled on the jersey Target. But you should get a confirmation from the Feign devs or do your own tests and review before using it in an unsafe way.
I was also looking, but unfortunately found nothing. The only signs provides in Spring configuration. The builder is defined as bean in scope prototype, so should not be thread safe.
#Configuration
public class FooConfiguration {
#Bean
#Scope("prototype")
public Feign.Builder feignBuilder() {
return Feign.builder();
}
}
reference: http://projects.spring.io/spring-cloud/spring-cloud.html#spring-cloud-feign-hystrix
After a deep dive into the feign-core code and a couple other feign modules (we needed additional support for things that weren't there so I had to modify some stuff -- plus, this question made me curious so I took another look), it looks like you should be safe re-using Feign clients in a multi-threaded environment as long as all of your local code (such as any custom Encoder, Expander, or RequestInterceptor classes, etc) has no mutable state.
The Feign internals don't store much in the way of mutable state, but some things are cached and re-used (thus may be called from multiple threads at the same time, if you are calling your Feign target's methods from multiple threads at the same time), so your plugins should be stateless.
It looks to me like all the main Feign modules were written with immutability and statelessness in mind as a goal.
In feign/core/src/main/java/feign/Client.java, there is a comment
/**
* Submits HTTP {#link Request requests}. Implementations are expected to be thread-safe.
*/
public interface Client {
So, from the designer's point of view, it should be thread-safety.
My question is related to the bll,dal,interfaces.
My project's constructure more or less like this.
BLL, DAL, OBJ and 3 layer architecture
(As I dont repeat question and codes again,I give the link here)
My question is why should I use interfaces,what is the benefits.and how can apply interfaces based on the project structure which is gaved above.
could u provide link or answers.thank you all
Interfaces allow you to define the behavior without the actual implementation, think of it as a contract.
If you only have one implementation, then an interface is not very useful and is not recommended.
Where interfaces shine, is when you have multiple implementations of the same logic. Say for example the data access layer (DAL), like this:
public interface IPersonRepository
{
Person CreatePerson(string firstName, string lastName, int age);
Person LoadPerson(int personId);
Person SavePerson(string firstName, string lastName, int age);
bool DeletePreson(int personId);
}
Now if you have a SQL Server database, then you could have a repository class that implements the IPersonRepository interface, like this:
public class SqlServerPersonRepository : IPersonRepository
{
// Implement SQL Server specific logic here
}
Let's say you want to support Oracle, as well, then you create an OraclePersonRepository, like this:
public class OraclePersonRepository : IPersonRepository
{
// Implement Oracle specific logic here
}
What is also useful is that you can create a mock person repository (for testing), like this:
public class MockPersonRepository : IPersonRepository
{
// Implement mock logic here
}
Interfaces are useful in a lot of examples. To give you one of the most popular, consider the Repository pattern commonly used for Data Layer implementation.
Let's say I implement my DAL for SQL Server. In the future, my company decides to switch to MySQL. All of my BLL calls to the DAL are now vulnerable to being rewritten/dramatically modified.
If I had used an interface (say IRepository), I could have written SqlRepository, which implements IRepository. I would then have the BLL reference IRepository, using Dependency Injection to give SqlRepository to the BLL at runtime. When the business decided to use MySQL, I can then write MySqlRepository, implement IRepository, and then all of my BLL doesn't have to be rewritten to handle MySQL. In fact, my BLL doesn't even know SqlRepository or MySQLRepository exists. It just communicates via the interface IRepository.
Some other key uses for Interfaces are getting around the lack of multiple inheritance in C#, as well as for some Web Service implementations. I think for your current setup, the example I gave above is one of the more useful demonstrations of the usefulness and power of interfaces.
Definitely look up the Repository Pattern as well as Dependency Injection / Inversion of Control. Once you are comfortable with it, you'll find more and more places to use Interfaces to keep your code as loosely coupled as possible.
Here's a short example of the implementations of IRepository and SqlRepository:
public interface IRepository
{
List<string> GetUserIds();
void CreateUser(string userId);
bool DeleteUser(string userId);
}
public class SqlRepository : IRepository
{
public List<string> GetUserIds()
{
// Provide your implementation of GetUserIds.
// Connect to DB, retrieve data, return
}
public void CreateUser(string userId)
{
// Provide implementation
}
public bool DeleteUser(string userId)
{
// Provide implementation
}
}
I have an asp.net process which also consumes messages from a servicebus (MassTransit). For webrequests my database session is resolved with a PerWebRequest lifestyle.
But when the process consumes a message from MassTransit I need the database session to have another lifestyle, as no HttpContext is available.
I have made this:
public class PerRequestLifeStyleManager : ILifestyleManager
{
readonly PerWebRequestLifestyleManager perWebRequestLifestyleManager;
readonly PerThreadLifestyleManager perThreadLifestyleManager;
public PerRequestLifeStyleManager()
{
perWebRequestLifestyleManager = new PerWebRequestLifestyleManager();
perThreadLifestyleManager = new PerThreadLifestyleManager();
}
public void Init(IComponentActivator componentActivator, IKernel kernel, ComponentModel model)
{
perWebRequestLifestyleManager.Init(componentActivator, kernel, model);
perThreadLifestyleManager.Init(componentActivator, kernel, model);
}
public object Resolve(CreationContext context)
{
return GetManager().Resolve(context);
}
public bool Release(object instance)
{
return GetManager().Release(instance);
}
public void Dispose()
{
GetManager().Dispose();
}
ILifestyleManager GetManager()
{
if (HttpContext.Current != null)
{
return perWebRequestLifestyleManager;
}
return perThreadLifestyleManager;
}
}
Can anyone tell me, if this is the right way to go? And if it isn't, what is?
Thanks.
EDIT: I have just updated the question with some code that seems to work (before it was untested). I still am eager to know if this - seen from a Windsor perspective - is safe and sound.
Try using one of the hybrid lifestyles.
By using the Castle Windsor extension, you should just be able to have your ISession as a dependency on the constructor of the consumer class. That way, the container will manage the lifecycle of the ISession, and dispose of it once the consumer is disposed by MT.
If you need even more control, you can look at how the WindsorConsumerFactory is implemented to wrap the resolution and release of the consumer class instance around the delivery of the message to the consumer.
If you need to inject something beyond that, you can also use an interceptor:
Unit of work when using MassTransit
Basically I'm trying to create a SessionManager class which I can use to manage sessions in my MVC applications. For that I'm thinking the best way of doing so is by creating a wrapper class for HttpContext which would then allow me to access HttpContext.Current.Session.
To be honest, I'm not really sure about the whole thing, I just feel it's the logical way of doing so. I also want to create an ISessionManager and ISession interfaces, and then implement them according to my application's needs. For my current project, and for now, I need a InProc session management, but I might need to store session data in MSSQL Server when we decide to expand and use a web farm or a garden. That's why I'm trying to build a sort of an extensible framework right from the start.
Final note, I will be using Microsoft Unity to inject the concrete SessionManager of choice. I believe that's a good way to maintain a certain level of abstraction.
Any suggestions for achieving all that?
Thanks in advance! :)
Ok here's what I came up with, but I'm not sure that's the right way of doing this so your opinions are most welcome!
ISessionManager:
public interface ISessionManager
{
void RegisterSession(string key, object obj);
void FreeSession(string key);
}
SessionManager:
public class SessionManager : ISessionManager
{
private IDictionary<string, object> sessionDictionary;
public SessionManager(IDictionary<string, object> _sessionDictionary)
{
sessionDictionary = _sessionDictionary;
}
public IDictionary<string, object> Session
{
get
{
return sessionDictionary;
}
}
public void RegisterSession(string key, object obj)
{
sessionDictionary[key] = obj;
}
public void FreeSession(string key)
{
sessionDictionary[key] = null;
}
}
Then when I want to instantiate the class (inside my web app), I would do something like that:
var sessionManager = new SessionManager(HttpContext.Current.Session);
sessionManager.RegisterSession["myKey"] = someObject;
But I would prefer to avoid using magic strings as the key. I could include a constant string property like sessionKey = "myKey" in the class, but that would mean I could only store one object in the session manager, right?
Feedback please. :)