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 7 years ago.
Improve this question
Dependency Injection design pattern is said to be helpful for loose coupling, however I cannot understand how it can be achieved since the calling object has to pass the dependencies in the constructor to the service?
Please explain?
I cannot understand how it can be achieved since the calling object has to pass the dependencies in the constructor to the service?
The calling object does not have to pass the dependencies in the constructor of the service.
The calling object will have the an implementation of the service injected into its constructor like this:
public class CallingObject
{
private readonly IService m_Service;
public CallingObject(IService service)
{
m_Service = service;
}
public void DoSomething()
{
m_Service.AskForService();
}
}
The entity that is responsible for wiring all objects together is the composition root.
So its the composition root that has to pass the dependencies into the constructor to the service.
The only disadvantage I found is that highlights design problems and causes many programmers to blame dependency injection for the design problems.
I'm sure that Krzysztof Koźmic can explain it better than me. Please read this.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 months ago.
Improve this question
I've just integrated a new devteam, which is using grails. I'm new to grails/groovy too, so the question is possibly stupid, but I need some advice.
The legacy code I'm manipulating is using a lot of StringUtils from apache, and I can't find a good point why they're doing that. I've suggested to use groovy truth instead, and avoid importing an unnecesseary class, but they keep on not correcting existing code, and using it in new code.
So, my question is : are there any advantages I did'nt see, for that use case ?
Example of code :
if (StringUtils.isNotEmpty(params.invoiceEventId)) {
invoiceEvent = InvoiceEvent.findById(params.invoiceEventId)
}
Thanks for your wisdom
Look at the source code of both solutions:
StringUtils
public static boolean isNotEmpty(final CharSequence cs) {
return !isEmpty(cs);
}
public static boolean isEmpty(final CharSequence cs) {
return cs == null || cs.length() == 0;
}
and StringGroovyMethods:
public static boolean asBoolean(CharSequence string) {
return string.length() > 0;
}
The methods are almost identical. The only difference, is that null-check in Groovy is done outside.
Ergo, there's no need to use the long call to the 3rd party library in Groovy or Grails.
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 1 year ago.
Improve this question
I've been wondering if it was possible to have a MVVM architecture with no reference of the ViewModel in the ViewController, I understand that it needs this reference because ViewModel works as a DataContext but I'm trying to figure it out, I want to isolate as much as possible responsibilities and dependency injection between Views and ViewModel. Have you any idea on how it is possible to achieve that in a MVVM pattern in Swift?
Let`s have a look your ideas step by step in MVVM aspects
"No reference of ViewModel in the ViewController or View."
It is not a good idea. By referencing to viewmodel in your view you notify viewmodel. That does not mean you need to do logic in your view or viewcontroller.
"I want to isolate as much as possible responsibilities and dependency injection between Views and ViewModel."
Exactly! ViewModel handle the all logic. View needs to be lightweight and no logic. There are many approaches in terms of binding your view to viewmodel and separating concerns. I can give an example below.
Move your datasource from view to viewmodel. For example if you working a tableviewdatasource then make a generic datasource( you can find many examples by google ) for your tableViewDataSource. Your viewcontroller will be something like below:
private var dataSource : YourTableViewDataSource<YourData>!
private var yourViewModel: YourViewModel!
self.yourTableViewDataSource = dataSource
func updateDataSource() { }
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 6 years ago.
Improve this question
public interface IEntityService < T> : IService where T : class
{
void Create(T entity);
void Delete(T entity);
IEnumerable<T> GetAll();
void Update(T entity);
T SelectById(object pk);
}
What is 'T' of here?
Why we have defined class?
What is 'T' = T is a generic type parameter
You can assign any Type value to it.
Why we have defined class ?
But on your example it (i.e. T) must be a Class type.That is the constrain which it has been defined like this where T : class.
What are Generics ?
It allows you to delay the specification of the data type of
programming elements in a class or a method, until it is actually used
in the program. In other words, generics allow you to write a class or
method that can work with any data type.
Some Advantages of using Generics :
It helps you to maximize code reuse, type safety, and performance.
You can create your own generic interfaces, classes, methods, events,
and delegates.
You may create generic classes constrained to enable access to
methods on particular data types.
You can learn more about it using these articles :
Generics
Generics
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I have one repository that internally (on some methods) will need to use another repository.
I am trying to put all dependencies on the constructor, passing interfaces as arguments. However I don't know how to deal with this specific scenario.
Should I pass also this repository as an argument? Even though I will not use it on every method inside?
Thanks
You don't have any problem for making a repository depend on another repository. And, yes, pass it as a parameter
I'm assuming you're making dependency injection, specifically constructor injection.
Instancing an extra repository, which some times won't be used (because not all method use it) it's not such a terrible overhead that makes you to avoid it. If it was a more expensive resource (like opening a file or DB connection) you could use some alternative technique. For example expose the second repository in a property with a backing field which is populated in the first call to the property getter using service location, i.e. finding it directly in your container, or an smarter solution, provided but some of the DI frameworks, which does this kind of thing automatically, like Unity's Lazy and similar solutions.
But I insist, in this case, the overhead doesn't justify it.
NOTE: you could also use the property or Lazy technique if you had a dependency loop (circular dependency), to break the loop and make it work. However, int this case, it's much better to refactor your classes, (extracting a thrid class) to avoid the circular references. This is not your case.
I would probably make a service layer on top of the repositories. Inject both repositories into the service layer.
public LibraryCatalogueService {
IBookRepository _books;
IAuthorsRepository _authors;
public LibraryCatalogueService (IBookRepository books, IAuthorRepository authors)
{
_books = books;
_authors = authors;
}
public List<BookWithAuthor> GetBooksWithAuthors()
{
//do stuff to get books and get authors and then join them.
//return the list
}
}
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
can someone suggest the ideal Unit test cases that may fit in across each of the layers .
(which otherwise can be called as a standard).
for instance, in an ASP.NET MVC applictaion using a Repository pattern -
Controller - can assert for View names and format of the data returned to the views , from the controller action methods( i couldnt think of more , if u can please suggest).
Services Layer - ?? what can be written. because they in turn depend on the layers underneath.. ( can some one suggest a Unit Case with example for sevices layer)?.
One trivial question to finish off. Irrespective of the layers , the method being tested makes calls to other instance methods/static methods say,
public List<string> MethodUnderTest()
{
instance.SomeOtherMethod();
StaticMethod();
}
in each case it is neccesary to mock the methods calls by moving that to interfaces .? any thoughts on that . ( coz unit Testing by nomenclature should not depend on anything)
Can some
I recommend reading the Art of Unit Testing. It covers this stuff in detail.