What is the difference between a service layer and a repository? I have worked through a lot of demo ASP.NET MVC apps and most of them have just repositories. And some have a mixture of both. When do you use just repositories and when do you use services / or both? The same is true for ASP.NET web apps.
Repositories act just as gateways to your data storage (sql database, xml file etc.) while services usually implement some business rules on your data before sending the data to be saved in the database via a repository.
consider this example:
class UserRepository : IUserRepository
{
public void Create(User userToCreate)
{
//update tracking and save to repository
_userToCreate.DateCreated = DateTime.Now;
_dataContext.AddNew(userToCreate);
}
}
class UserService : IUserService
{
private IUserRepository _repository;
public UserService(IUserRepository repository)
{
_repository = repository;
}
public void Create(User createdByUser, User userToCreate)
{
//implement some business rules
if(!createdByUser.HasRights(UserRights.CanCreateNewUser))
throw new Exception("This user '"+createdByUser.Name+"' does not have the rights to create a new user");
//update rules auditing
_userToCreate.CreatedByUserId = createdByUser.Id;
//save entity to repository
_repository.Create(userToCreate);
}
}
Then in your Controller action you will use the service directly where all your business rules can be applied. That way you can test you controllers, business rules (services) and persistence (repositories) separately/independently using mocks.
public ActionResult CreateUser(User newUser)
{
if(ModelState.IsValid)
{
_userService.Create(this.CurrentUser, newUser);
if(newUser.Id > 0)
return RedirectToAction("UserCreated");
}
return View(newUser);
}
A repository typically handles data-access only. A service layer will use a repository, and apply any additional business logic. Think of the repository as a re-usable layer than could be used by anything that wants to access your data. Different apps might have different business rules (that would go in the service layer), but could all use the same repository layer implmentation
Just as a compendium to qntmfred answer please have a look at the following resources:
Service Layer Guidelines
Service Layer in Web applications
Related
I have the following code that registers an instance to the .net services collection for Azure services.
services.AddSingleton(x => Microsoft.Azure.Management.Fluent.Azure.Authenticate(azureCredentials)
.WithSubscription(Configuration[ConfigurationConstants.AzureAuth_SubscriptionId]));
This code then resolves an instance of the IAzure in my service class where I can access all the services available like _azure.SqlServers.ListAsync etc.
I want to have a way so I can work with two Azure subscriptions and thus register two instances to the services collection and then be able to resolve the one that I want. You can check here for a similar example of what I want, it's about the blob storage though.
As with the linked example, you would need a way to uniquely differentiate the services and most likely need to use a factory pattern design
public interface IAzureFactory {
IAzure GetSubscription(string subscriptionId);
}
The subscription Id could be used to separate the services, but that would require getting the current subscription id from the service to find the match
public class AzureFactory : IAzureFactory {
private readonly IEnumerable<IAzure> subs;
public AzureFactory (IEnumerable<IAzure> subs) {
this.subs = subs;
}
public IAzure GetSubscription(string subscriptionId) {
return subs.FirstOrDefault(_ => _.SubscriptionId == subscriptionId) ??
throw new InvalidArgumentException("invalid subscription Id)";
}
}
From there it is only a matter of registering the different subscriptions.
services.AddSingleton<IAzureFactory, AzureFactory>();
services
.AddSingleton(x => Microsoft.Azure.Management.Fluent.Azure.Authenticate(azureCredentials)
.WithSubscription(Configuration[ConfigurationConstants.AzureAuth_SubscriptionId1]));
services
.AddSingleton(x => Microsoft.Azure.Management.Fluent.Azure.Authenticate(azureCredentials)
.WithSubscription(Configuration[ConfigurationConstants.AzureAuth_SubscriptionId2]));
And using the factory to get the desired subscription
//...
private readonly IAzure azure;
//ctor
public MyService(IAzureFactory factory) {
azure = factory.GetSubscription(...);
}
//...
We are using classes inheriting from Registry to configure our StructureMap container in our ASP.NET MVC 4 application startup.
Some excerpt from one of the registry-classes:
For<ISomeInterface>().HybridHttpOrThreadLocalScoped().Use<SomeImplementation>();
We would like use different instances of our interfaces depending on the context. (For example switching from database "online" mode to "maintenance" mode where everything is saved on filesystem; therefore using other interfaces (i.e. repositories) all over the place in our application)
For example by default it should use SomeImplementation but when passing some kind of querystring in the url (to name a simple "context" scenario) it should use SomeOtherImplementation.
How can this be achieved for multiple interfaces/types?
Should we use named instances for this? Like:
For<ISomeInterface>().HybridHttpOrThreadLocalScoped().Use<SomeOtherImplementation>().Named("other");
I read about StructureMap Profiles but i'm not sure if this is the right way to go.
Should we use profiles for this? Like i.e.:
Profile("other", profileExpression =>
{
For<ISomeInterface>().HybridHttpOrThreadLocalScoped().Use<SomeOtherImplementation>();
});
How can we switch different configurations on the fly?
ObjectFactory.Container.SetDefaultsToProfile("other");
This way? (At what stage in mvc "life-cycle" this can happen at the earliest?)
Can this be a temporary switch for just the current request or current users session?
Thanks in advance!
From my experience, runtime configuration like this is best achieved using an abstract factory that is responsible for creating your dependency during runtime.
This dependency can then be registered with StructureMap like so:
Your registry:
public class StorageRegistry : Registry
{
public StorageRegistry()
{
...
this.For<IDataStoreInstance>().Use(ctx => ctx.GetInstance<DataStoreAbstractFactory>().ConfigureStorage());
...
}
}
Now your DataStoreAbstractFactory is responsible for creating and configure the necessary storage instance based on your configuration. As DataStoreAbstractFactory is now registered with StructureMap you're able to inject the necessary dependencies into it for determining which storage method to use.
Implementation example:
public class DataStoreAbstractFactory
{
public DataStoreAbstractFactory()
{
// Dependencies to figure out data storage method can be injected here.
}
public IDataStoreInstance ConfigureStorage()
{
// This method can be used to return type of storage based on your configuration (ie: online or maintenance)
}
}
public interface IDataStoreInstance
{
void Save();
}
public class DatabaseStorage : IDataStoreInstance
{
public void Save()
{
// Implementation details of persisting data in a database
}
}
public class FileStorage : IDataStoreInstance
{
public void Save()
{
// Implementation details of persisting data in a file system
}
}
Usage:
Your controller/services or whatever are now completely unaware of what storage method they're using when accessing and persisting data.
public class UpdateController : Controller
{
public IDataStoreInstance StorageInstance { get; set; }
public UpdateController(IDataStoreInstance storageInstance)
{
StorageInstance = storageInstance;
}
[HttpPost]
public ActionResult Index()
{
...
this.StorageInstance.Save();
...
}
...
}
What are the best practices for connecting to a Azure Table Storage from a ASP.NET MVC or Web API app?
Right now I've made a StorageContext class which holds a reference to the CloudStorageAccount and CloudTableClient, like this:
public class StorageContext
{
private static CloudStorageAccount _storageAccount;
private static CloudTableClient _tableClient;
public StorageContext() : this("StorageConnectionString") { }
public StorageContext(string connectionString)
{
if (_storageAccount == null)
_storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings[connectionString].ConnectionString);
if (_tableClient == null)
_tableClient = _storageAccount.CreateCloudTableClient();
}
public CloudTable Table(string tableName)
{
var table = _tableClient.GetTableReference(tableName);
table.CreateIfNotExists();
return table;
}
}
And my controller I'm using it like this:
public class HomeController : ApiController
{
private StorageContext db;
public HomeController() : this(new StorageContext()) { }
public HomeController(StorageContext context)
{
this.db = context;
}
public IHttpActionResult Get()
{
var table = db.Table("users");
var results = (from user in table.CreateQuery<User>()
select user).Take(10).ToList();
return Ok<List<User>>(results);
}
}
Is this the preferred way of doing it?
The API is going to be used on a high traffic site with > 1000 req/sec.
I also need unit tests. Using it like above it I can pass in another connString name and instead connect to the Azure Storage emulator in my unit tests.
Am I on the right track or are there better ways to connect?
Actually your question
What are the best practices for connecting to a Azure Table Storage
from a ASP.NET MVC or Web API app?
could be restated like "What are the best practices to use data access layer in web application". It is the same.
You can find a lot of answers about data access layer best practices. But iron rule here keep your data access layer separated from your controller or presentation. The best way to use it through Model in scope of MVC pattern, or you can think about Repository and/or Unit of work pattern if you like them.
In your example your data access logic is already wrapped in StorageContext, which is fine, I would additionally extract interface and use DI/IoC and dependency resolver for it. That's all when speaking about your code snippet. You are on right way.
I am looking to integrate NServiceBus into an existing ServiceStack web host. ServiceStack is currently using the built in Funq IoC container. NServiceBus has been configured (elsewhere in the system) to use Unity for IoC.
ServiceStack has a feature whereby IRequestContext will be automatically injected when it finds the IRequiresRequestContext interface on a class. NServiceBus has a similar feature for Message Mutators, via the IMutateOutgoingTransportMessages interface.
The application is a multi-tenant application. Single application, which via an API Key, passes an account code through to the NServiceBus handler (indirectly via a provider that is called on the construction of the handler's constructor injection using Unity).
My problem arises in ServiceStack. I am using a request filter to drag the API key out of the request headers, which I look-up in a database, and then finally write into the IHttpRequest.Items collection:
appHost.RequestFilters.Add((req, res, requestDto) =>
{
var tenant = tenantRepository.GetByApiKey(
req.Items.Add("AccountCode", tenant.AccountCode);
}
I then have an NServiceBus transport message mutator, that implements that IRequiresRequestContext interface, and this class is located in the same assembly as the ServiceStack services registered in the AppHost:
public class MessageHeaderMutator : IMutateOutgoingTransportMessages, INeedInitialization, IRequiresRequestContext
{
#region IRequiresRequestContext Members
public IRequestContext RequestContext { get; set; }
#endregion
#region IMutateOutgoingTransportMessages Members
public void MutateOutgoing(object[] messages, NServiceBus.TransportMessage transportMessage)
{
transportMessage.Headers.Add("AccountCode", RequestContext.Get<IHttpRequest>().Items["AccountCode"].ToString());
}
#endregion
#region INeedInitialization Members
public void Init()
{
Configure.Instance.Configurer.ConfigureComponent<MessageHeaderMutator>(DependencyLifecycle.InstancePerCall);
}
#endregion
}
However, RequestContext is never injected, and is always null. My theory is that the two interface injections, injected via the two separate frameworks, are somehow clashing.
I have a workaround, which is to use the ServiceStack HostContext.Items instead, as per this discussion, but I am concerned that the HostContext is not a per request collection, so I might end up writing data to the wrong tenant. Workaround is:
// app host
appHost.RequestFilters.Add((req, res, requestDto) =>
{
var accountCode = tenantRepository.GetByApiKey(
HostContext.Instance.Items.Add("AccountCode", client.AccountCode);
}
// message mutator
public class MessageHeaderMutator : IMutateOutgoingTransportMessages, INeedInitialization
{
#region IMutateOutgoingTransportMessages Members
public void MutateOutgoing(object[] messages, NServiceBus.TransportMessage transportMessage)
{
var accountCode = HostContext.Instance.Items["AccountCode"].ToString();
transportMessage.Headers.Add("AccountCode", accountCode);
}
#endregion
#region INeedInitialization Members
public void Init()
{
Configure.Instance.Configurer.ConfigureComponent<MessageHeaderMutator>(DependencyLifecycle.InstancePerCall);
}
#endregion
}
My question is therefore twofold:
The first is, why does IRequiresRequestContext not correctly inject RequestContext into the Message mutator, or is there a way to inject RequestContext manually?
Is the use of the HostContext safe to assume it is per request?
Bonus question: Is the use of two separate IoC containers in the same project (Unity in NServiceBus and Funq in ServiceStack) a really bad idea? Would it be smarter to get ServiceStack to use the same Unity IoC container as NServiceBus?
P.S. This is NServiceBus 4 (beta at time of writing).
It is precisely because you're using 2 different containers that DI doesn't work for you out of the box for objects registered in different containers.
You don't necessarily need to standardize on a single container (though it would save you from dealing with these sorts of issues all the time).
What you can do to keep working with both containers is to tell the NServiceBus container how to resolve IRequiresRequestContext like this:
public class RequestContextBootstrapper : INeedInitialization
{
public void Init()
{
Configure.Component<IRequiresRequestContext>( /* get object from ServiceStack */ );
}
}
You can access the ServiceStack container via AppHostBase.Container and use it to resolve your objects as Udi suggested.
I have a WPF application which talks to a WCF service hosted in IIS. I am also using ASP.NET authorization and authentication to access the service methods. There is also a relatively thin web based interface to the system as well.
What I want is to make use of the ASP.NET Profiles. For example - load profile from server, make changes and then save back to the server. All that with WCF Service calls.
This is my sample User Profile class which is declared server side. I have also defined the appropriate entries in the web.config so it works properly.
public class UserProfile: ProfileBase
{
public static UserProfile GetUserProfile(string username)
{
return Create(username) as UserProfile;
}
public static UserProfile GetUserProfile()
{
return Create(Membership.GetUser().UserName) as UserProfile;
}
public int? XMLVersion
{
get
{
return this["XMLVersion"] as int?;
}
set
{
this["XMLVersion"] = value;
}
}
}
However I cannot pass it back to the client because ProfileBase is not serializable. Of course I can declare data transfer class which will transfer data back and forth from the profile but it does not look as a very good solution.
So far I am unable to find information how to implement it. Can someone help me with that or point me to another solution?
The WCF profile service does what you are asking for. Have a look at it here.
You can see the list of methods it provides in this MSDN page