patterncsharpMinor
Factory for report handlers
Viewed 0 times
factoryreportforhandlers
Problem
Below is my try.
Code Metrics still showing Maintainability Index to 60.
What I am missing here or how can I improve my implementation?
//DAL
//This is my interface
namespace iPublisher.DAL.Interfaces
{
public interface IReportHandler
{
IEnumerable FetchDocuments(int clientId, int pager);
}
}
//my concrete class
public class ReportHandler : IReportHandler
{
public IEnumerable FetchDocuments(int clientId, int pager)
{
//LINQ
}
}
//Factory Interface
namespace iPublisher.DAL.Interfaces
{
public interface IReportFactory
{
IReportHandler Create(int factoryId);
}
}
//Factory class
namespace iPublisher.DAL.Factory
{
public class ReportFactory : IReportFactory
{
private IReportHandler reportObj;
public IReportHandler Create(int factoryId)
{
switch (factoryId)
{
case 1:
reportObj = new ReportHandler();
return reportObj;
default:
throw new ArgumentException("");
}
}
}
}
//UI Layer
namespace iPublisher.Controllers
{
[Authorize]
[SessionExpire]
public class ReportsController : Controller
{
ReportFactory factObj = new ReportFactory();
public string GetAllDocuments(string url,int pager =0)
{
if (SessionInfo.IsAdmin)
{
var documentsDataJSON = GetDocumentIntoJson(SessionInfo.ClientID, pager);
return documentsDataJSON;
}
else
{
return "Sorry!! You are not authorized to perform this action";
}
}
private string GetDocumentIntoJson(int clientId, int pager)
{
IReportHandler reportObj = factObj.Create(1);
var documents = reportObj.FetchDocumentsList(clientId, pager);
string documentsDataJSON = JsonConvert.SerializeObject(documents);
return documentsDataJSON;
}
}
}Code Metrics still showing Maintainability Index to 60.
What I am missing here or how can I improve my implementation?
Solution
Not sure if that's going to improve the maintainability index, but
-
You're misimplementing Inversion of Control. IoC is when your dependency (namely,
Read up on Inversion of Control and Dependency Injection and how they can improve code maintainability and testability. Don't use them unless it is an educated choice to do so.
-
You're using a Factory where it has no benefit.
Read up on the different kinds of factories (Factory from DDD, Factory method and Abstract Factory from Go4). Don't use Factories except where there's a clear advantage to doing so.
-
The code is too complicated for what it does.
Why the
The
Why the intermediate variables
-
Naming is awkward and violates the Principle of Least Surprise.
Why would you expect a ReportHandler to Create a report, while ReportFactory creates a... ReportHandler?
Why does
Don't try to mimic code samples or game a maintainability analysis tool. Learn about the philosophy behind the big design principles/patterns and decide for yourself if, where and how to apply them.
-
You're misimplementing Inversion of Control. IoC is when your dependency (namely,
IReportHandler) is given to you from outside the class. It isn't the case here. It defeats the whole purpose of having an abstract dependency instead of a concrete one.Read up on Inversion of Control and Dependency Injection and how they can improve code maintainability and testability. Don't use them unless it is an educated choice to do so.
-
You're using a Factory where it has no benefit.
Read up on the different kinds of factories (Factory from DDD, Factory method and Abstract Factory from Go4). Don't use Factories except where there's a clear advantage to doing so.
-
The code is too complicated for what it does.
Why the
factoryId, switch statement and magic value 1? The
url parameter is never used. Why the intermediate variables
documentsDataJSON when you could just return and save one line of code for more clarity?-
Naming is awkward and violates the Principle of Least Surprise.
Why would you expect a ReportHandler to Create a report, while ReportFactory creates a... ReportHandler?
Why does
FetchDocuments() not return a list of Documents, but a list of DocumentMappers?Don't try to mimic code samples or game a maintainability analysis tool. Learn about the philosophy behind the big design principles/patterns and decide for yourself if, where and how to apply them.
Context
StackExchange Code Review Q#150382, answer score: 6
Revisions (0)
No revisions yet.