Patterns in Action 4.0 - SOA - is it scalable?

In the action service class of the service layer project (ActionService.cs), there are multiple static data access objects

My question is,

private static readonly ICategoryDao _categoryDao = DataAccess.CategoryDao;
private static readonly IProductDao _productDao = DataAccess.ProductDao;
private static readonly ICustomerDao _customerDao = DataAccess.CustomerDao;
private static readonly IOrderDao _orderDao = DataAccess.OrderDao;
private static readonly IOrderDetailDao _orderDetailDao = DataAccess.OrderDetailDao;

1) If I have a project with over 100 tables/entities, will performance degrade if I'm gonna have over 100 of these static data access objects in my service layer?

2) If I set WCF's request type from PerSession to PerCall (because I do not want to handle sessions and I do not need any state data), is there gonna be any performance implications? If yes, what changes do I have to make if I want my request type to be PerCall?

Parity Bit, Apr 10, 2014

Any insights or comments?

May 06, 2014

Reply 1

I can't really answer your question on how this might affect your application's performance, but it might prove labor intensive in maintaining.

I have purchase the DoFactory PIA for many years and have found them extremely helpful in understanding design patterns and how they work, In Action. And I really am not taking anything away from what they have created here, but I don't believe they built these demo applications as a Starter Kit to actually implement in your application.

I'm not saying that you can't either, I'm just saying that I'm sure they built these applications as tangible demonstrations that you can touch and manipulate and feel and play with, but not necessarily use.

What I learned from their applications, I was able to implement to create my own infrastructure that worked for me. The great thing about design patterns is that it gives you power in knowledge in how to solve problems in your application. But that doesn't mean that you have to use them.

What I mean by that is that if you decide you want to use a certain tool, use it, whether or not it involves the use of a pattern. Example: I want to use the Entity Framework for ORM with SQL Server. Right out of the box this gives me access to many shortcuts in the way I need to access my data.

With MVC I have even more:

DataAnnotations - I can decorate my classes for easy server-side and client-side validation
DbContext - this allows for POCO's to be used as my entities
Dependency Injection - I use Ninject for dependency injection in my constructors so I never have the "new" keyword in my constructors when instantiating an instance of a class
and more

Think about the framework you want to use and see if there are tools, such as Entity Framework, Unit Of Work, DataAnnotations, etc., that help you build your application in an easier way. You really want to think about maintenance of your application, because the only constant in applications, is change! So you will at some point in time need to change something, so you need to think of how to future-proof your application. If the PIA infrastructure will do it, then by all means, use that pattern. If you don't think it will, you need to make a choice and think about what will.

There a options out there, and I have one, but the choice is still yours. http://www.designpatternscentral.net/s/1075. Do not discount what they have built for you, but really understand what they have done. They gave you the framework on how patterns can be put together and executed to work in a real-world scenario. It's up to you to decide whether you can use it directly, or use information from it to build your super application.

I hope this helps.

King Wilder

King Wilder, Sep 21, 2014